OCI-c: SOA storage scale up errors

To avoid the error PSM-LCM-06102 Unable to add storage to the nodes of service [xxx] in identity domain [yyy], while trying to scale up the storage for a manager server compute, check, on the admin server compute, that the following rsa key is properly configured with the rw——- ownership.

ls -l /u01/app/oracle/tools/home/otools/.ssh/id_rsa 
Advertisements

OCI: PSM and OCI subnet policies

To allow a subnet to be referenced from PSM, for example when provisioning a DBCS, navigate to the OCI console and:

Set the compartment context.

Navigate in Governance => Identity => Policy and create the following 4 statements

Allow service PSM to inspect vcns in compartment <compartment>
Allow service PSM to use subnets in compartment <compartment>
Allow service PSM to use vnics in compartment <compartment>
Allow service PSM to manage security-lists in compartment <compartment>

 

Reference:

https://docs.cloud.oracle.com/iaas/Content/General/Reference/PaaSprereqs.htm#prereqs

DB12c: Support for varchar2 32k

To switch a RAC database in varchar2 32k mode:

sqlplus / as sysdba <<EOF
alter system set cluster_database=false scope=spfile;
alter system set max_string_size=extended scope=spfile;
EOF

srvctl stop database -d <db> -o immediate

sqlplus / as sysdba <<EOF
startup upgrade
@?/rdbms/admin/utl32k

alter session set container=PDB$SEED;
alter system set max_string_size=extended scope=spfile;
@?/rdbms/admin/utl32k

alter session set container=xxx;
alter system set max_string_size=extended scope=spfile;
@?/rdbms/admin/utl32k

alter session set container=cdb$root;
alter system set cluster_database=true scope=spfile;
shutdown immediate;
startup mount;

 

Beware there is NO invalid materialized view present in the PDB or the upgrade may fail with a similar error as follow:

ORA-00942: table or view does not exist
ORA-06512: at "<PDB>.UTL32K_PARSEQUERY", line 15
ORA-00942: table or view does not exist
ORA-00942: table or view does not exist
ORA-00942: table or view does not exist
ORA-00942: table or view does not exist
ORA-00942: table or view does not exist

ORA-00942: table or view does not exist
ORA-00942: table or view does not exist
ORA-00942: table or view does not exist
ORA-06512: at "SYS.DBMS_SQL", line 1199

OCI: Ansible setup for OCI on OL6.9

Relevant document is here and here.

Not that Ansible needs Python 2.7+.

 

How to install (root)

Install should probably be along these lines on OL6.x. It is better to install in such a way that it can cohabit with multiple python versions.

yum install python27 python33 git
alternatives --install /usr/bin/python python /usr/bin/python2.7 2
alternatives --install /usr/bin/python python /usr/bin/python3.3 1
scl enable python27 bash
pip2 install oci
pip2 install ansible
git clone https://github.com/oracle/oci-ansible-modules.git
cd oci-ansible-modules
./install.py

 

Sample usage

#1 Switch to the python27 context

scl enable python2.7 bash

 

#2 Configure the file $HOME/.oci/config with a similar content

[DEFAULT]
user=ocid1.user.oc1..xxxxxxxxxxxxxxxxxxxxxxxxxa
fingerprint=xxxxxxxxxxxxxx
key_file=~/.ssh/cloudadmin.pem
tenancy=ocid1.tenancy.oc1..axxxx 
region=eu-frankfurt-1

 

#3 Configure a sample list_buckets.yml file with a similar content:

- name : List summary of existing buckets in OCI object storage
 connection: local
 hosts: localhost
 tasks:
 - name: List bucket facts
 oci_bucket_facts:
 namespace_name: '<tenant>'
 compartment_id: 'ocid1.tenancy.oc1..xxxx'
 register: result
 - name: Dump result
 debug: 
 msg: '{{result}}'

 

#4 Execute the script

ansible-playbook list_buckets.yml

[WARNING]: Unable to parse /etc/ansible/hosts as an inventory source

[WARNING]: No inventory was parsed, only implicit localhost is available

[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'

PLAY [List summary of existing buckets in OCI object storage] **************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************************************
ok: [localhost]

TASK [List bucket facts] ***************************************************************************************************************************************
ok: [localhost]

TASK [Dump result] *********************************************************************************************************************************************
ok: [localhost] => {
 "msg": {
 "buckets": [
 {
 "compartment_id": "xxxxx", 
 "created_by": "xxxxx", 
 "defined_tags": null, 
 "etag": "xxxxx", 
 "freeform_tags": null, 
 "name": "xxx", 
 "namespace": "xxxx", 
 "time_created": "xxxx"
 }, 
 ], 
 "changed": false, 
 "failed": false
 }
}

PLAY RECAP *****************************************************************************************************************************************************
localhost : ok=3 changed=0 unreachable=0 failed=0

 

OCI-c: eBS database provisioning on DBCS

This note is about OCI classic.

Provisioning eBS on OCI-C is straightforward. Potential glitches may come when using IDCS.

When provisioning the database on DBCS, when you specify the “Oracle DBaaS Cloud Service Endpoint”, answer only with the rest server endpoint, for example in EMEA: https://dbcs.emea.oraclecloud.com.

Then when asked for the “Oracle DBaaS Identity Domain”, answer with the identity service id (idcs-xxxxxxxxxxxxxxxx), this information is available from the service dashboard for dbaas.

Failure to do so would return “Unauthorized” errors.

If getting the error “Fatal: 400 bad request” during the creation of the DBCS orchestration, try to run the knife oc dbaas create command manually and see if the error may not be due to the DBCS subscription type HOURLY or MONTHLY, improperly choosen.

At the time of writing this note, available PSU for DBCS are:
JAN2018 – DATABASE PATCH SET UPDATE 12.1.0.2.180116 – 27001733
OCT2017 – DATABASE PATCH SET UPDATE 12.1.0.2.171017 – 26713565

 

EXD: Griddisk resizing

Complete MOS is 2176737.1.

To resize all asm disks then the griddisks that belongs to a disk group after they were created improperly, for example, too small or too large:

#Resize the asm disks

ALTER DISKGROUP <dg> RESIZE ALL SIZE <size>M REBALANCE POWER 64;

For a X6-2 Quarter Rack with 3 cells, in High redundancy, 2TB and 3TB per disk would give diskgroup sizes of 23TB and 35TB.

#2 Resize the griddisks

First check the griddisk names

dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size where name like \'<dg>.*\'"

Then proceed, cell per cell:

dcli -c mycell -l root "cellcli -e alter griddisk <name1>, <name2>,... <name12> SIZE=<size>M"