Oracle - SQL - MySQL DBA - Life Long Learning Experience

A small example to demonstrate this  plan_hash_value= 4160939255 sqlid = 0zwsk3sanq3mp SQL> set serveroutput on SQL> declare      ret binary_integer;      l_sql_id varchar2(13);      l_plan_hash_value number;  l_fixed varchar2(3);  l_enabled varchar2(3);  Begin    l_sql_id := '&&sql_id';   l_plan_hash_value := to_number('&&plan_hash_value');    l_fixed := 'Yes';    l_enabled := 'Yes';    ret := dbms_spm.load_plans_from_cursor_cache(        sql_id=>l_sql_id,        plan_hash_value=>l_plan_hash_value,        fixed=>l_fixed,        enabled=>l_enabled);    end;   /      select count(*) from dba_sql_plan_baselines ;       select SQL_HANDLE, PLAN_NAME from dba_sql_plan_baselines;      BEGIN   DBMS_SPM.CREATE_STGTAB_BASELINE(   table_name      => 'SPM_STAGETAB',   table_owner     => 'MONITOR',   tablespace_name => 'TOOLS'); END; DECLARE       my_plans number;       BEGIN         my_plans := DBMS

  Kong Native Solution Kong has its own native implementation of declarative config management. This is called db-less mode and as the name implies there is no database, instead the config is stored in a yaml file and is loaded into memory at start up and can also be refreshed. The yaml config is loaded into memory on each kong server individually so there is scope for having the config out of sync between kong servers. Not all plugins are supported on kong running in db-less mode, the most significant for us is the Oauth plugin, which is currently being used extensively, requires a db. https://docs.konghq.com/1.3.x/db-less-and-declarative-config/ Open Source Tools For the POC I used decK to manage the configuration. There are other utilities eg. kongfig and Maples7/kong-config-manager. But all the tools I looked at suffered from the same issue in that they do not directly integrate with vault and we don’t want to store kong secrets in gitlab. To get around this we will need to store s

  Overview The aim of this document is to provide a standard using best practices which all Terraform 0.12 code will follow. This should then created a more consolidated and standardised code base promoting greater familiarity to all squads code.   Variables and outputs should have descriptions:    All variables and outputs should have one or two sentence descriptions that explain their purpose. This is used for documentation.   Nested Modules (submodules) : If the root module includes calls to nested modules, they should use relative paths like ./modules/consul-cluster so that Terraform will consider them to be part of the same repository or package, rather than downloading them again separately.   resource/datasource tagging: follow AWS best practices -  https://aws.amazon.com/answers/account-management/aws-tagging-strategies/ for example, apart from the documentation side, it allows us to easily search for resources and setup budget reports per team if required at some point.   Poss

  This guide will describe with examples the major changes to be made to the Terraform code base during the first stage of the Terraform refactoring for the upgrade from 0.11 to 0.12. Lists of security group CIDR blocks variables As is, any CIDR blocks needed for security group rules have been passed into the module seperately and the CIDR block lists built within the module and then used by a security group rule Terraform resource or passed into another module which will then create a security group rule resource. Just looking at these variables being passed into the module at the calling service level doesn’t give much indication of what they may be being used for behind the scenes in the module. Where this occurs they should be replaced by complete list variables (although currently lists as a string seperated by “,”) with descriptive names as to their usage such as 1 variable "ec2_ssh_22_allowed_cidr_blocks" { 2 description = "List of CIDR blocks in string format s