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
Content is moved.
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
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
Relevant document is here and here.
Not that Ansible needs Python 2.7+.
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
#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
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
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"
