Pakistan's First Oracle Blog

AWS Systems Manager (SSM) is a managed service by AWS, which is used to configure and manage EC2 instances, other AWS resources, and on-premise VMs/servers at scale. SSM frees you up from having ssh or bastion host access to the remote resources.


Pre-requisites of SSM:

The managed instances need to have SSM agent running.
The managed instances need to be assigned an IAM role with policy AmazonEC2RoleforSSM.
The managed insatnces need to have a meaningful tag assigned to them to make it possible to manage them in bulk.

Example:

This example assumes that above pre-requisites are already there. For step by step instructions as how to do that, check this resource (https://aws.amazon.com/getting-started/tutorials/remotely-run-commands-ec2-instance-systems-manager/). This also assumes that all the instances
have been assigned tags like Env=Prod or Env=Dev.

Following is the script update_opatch.sh which was already bootstrapped to the EC2 instance at time of creation in userdata,
so its already present at /u01/scripts/update_opatch.sh

#/usr/bin/env bash -x
ORACLE_SID=`ps -ef | grep pmon | grep -v asm | awk '{print $NF}' | sed s'/pmon_//' | egrep "^[+]"`
export ORAENV_ASK=NO
. oraenv > /dev/null 2>&1
mv $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.$(date)
curl -T /tmp/ -u test@test.com ftps://
mv /tmp/p6880880_101000_linux64.zip $ORACLE_HOME
cd $ORACLE_HOME
unzip p6880880_101000_SOLARIS64.zip


Now just running following command in Systems Manager will update opatch on all the managed instances with tag Prod.

aws ssm send-command --document-name "AWS-RunShellScript" --comment "update_opatch.sh" --parameters commands=update_opatch.sh Key=tag:Env,Values=Prod

I often need to extract subset of data from one command so that it could be used in another during the DBA tasks performed through shell scripts.

One such requirement is that when you need to feed the name of ASM disks to the querydisks command.


For example, if you want to see the mapping of ASM disks to the devices at OS level, you need to run following command:

oracleasm querydisk -d

Now in order to get ASM diskname, you need to run

oracleasm listdisks

Now a sample output from oracleasm querydisk would be :

Disk "MYDISK" is a valid ASM disk on device [3,7]

In the above output, the 3 is the minor and 7 is major number of disk, which is often visible in OS level commands like iostat. How would you extract that 3 and 7 from above output?

Well, one way is to use awk -F command like following:

In order to extract 3, you would do:

Cat Disk "MYDISK" is a valid ASM disk on device [3,7] | awk -F[ '{print $2}' | awk -F, '{print $1}'

In order to extract 7, you would do:

Cat Disk "MYDISK" is a valid ASM disk on device [3,7] | awk -F[ '{print $2}' | awk -F, '{print $2}'

Hope that helps

This is quick spit-out of commands, I used on my test virtual machine to install PostgreSQL 11 on Oracle Enterprise Linux 7.



[root@docker ~]# curl -O https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-oraclelinux11-11-2.noarch.rpm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4952  100  4952    0     0   1889      0  0:00:02  0:00:02 --:--:--  1890
[root@docker ~]# rpm -ivh pgdg-oraclelinux11-11-2.noarch.rpm
warning: pgdg-oraclelinux11-11-2.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID 442df0f8: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:pgdg-oraclelinux11-11-2          ################################# [100%]
[root@docker ~]# yum list postgres*
Loaded plugins: langpacks, ulninfo
pgdg11                                                   | 4.1 kB     00:00   
(1/2): pgdg11/7Server/x86_64/primary_db                    | 141 kB   00:02   
(2/2): pgdg11/7Server/x86_64/group_gz                      |  245 B   00:02   
Available Packages
postgresql.i686                     9.2.24-1.el7_5           ol7_latest       
postgresql.x86_64                   9.2.24-1.el7_5           ol7_latest       
postgresql-contrib.x86_64           9.2.24-1.el7_5           ol7_latest       
postgresql-devel.i686               9.2.24-1.el7_5           ol7_latest       
postgresql-devel.x86_64             9.2.24-1.el7_5           ol7_latest       
postgresql-docs.x86_64              9.2.24-1.el7_5           ol7_latest       
postgresql-jdbc.noarch              42.2.5-1.rhel7.1         pgdg11           
postgresql-jdbc-javadoc.noarch      42.2.5-1.rhel7.1         pgdg11           
postgresql-libs.i686                9.2.24-1.el7_5           ol7_latest       
postgresql-libs.x86_64              9.2.24-1.el7_5           ol7_latest       
postgresql-odbc.x86_64              09.03.0100-2.el7         ol7_latest       
postgresql-plperl.x86_64            9.2.24-1.el7_5           ol7_latest       
postgresql-plpython.x86_64          9.2.24-1.el7_5           ol7_latest       
postgresql-pltcl.x86_64             9.2.24-1.el7_5           ol7_latest       
postgresql-server.x86_64            9.2.24-1.el7_5           ol7_latest       
postgresql-static.i686              9.2.24-1.el7_5           ol7_latest       
postgresql-static.x86_64            9.2.24-1.el7_5           ol7_latest       
postgresql-test.x86_64              9.2.24-1.el7_5           ol7_latest       
postgresql-unit11.x86_64            7.0-1.rhel7              pgdg11           
postgresql-unit11-debuginfo.x86_64  7.0-1.rhel7              pgdg11           
postgresql-upgrade.x86_64           9.2.24-1.el7_5           ol7_optional_latest
postgresql11.x86_64                 11.1-1PGDG.rhel7         pgdg11           
postgresql11-contrib.x86_64         11.1-1PGDG.rhel7         pgdg11           
postgresql11-debuginfo.x86_64       11.1-1PGDG.rhel7         pgdg11           
postgresql11-devel.x86_64           11.1-1PGDG.rhel7         pgdg11           
postgresql11-docs.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql11-libs.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql11-llvmjit.x86_64         11.1-1PGDG.rhel7         pgdg11           
postgresql11-odbc.x86_64            11.00.0000-1PGDG.rhel7   pgdg11           
postgresql11-plperl.x86_64          11.1-1PGDG.rhel7         pgdg11           
postgresql11-plpython.x86_64        11.1-1PGDG.rhel7         pgdg11           
postgresql11-pltcl.x86_64           11.1-1PGDG.rhel7         pgdg11           
postgresql11-server.x86_64          11.1-1PGDG.rhel7         pgdg11           
postgresql11-tcl.x86_64             2.4.0-2.rhel7.1          pgdg11           
postgresql11-test.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql_anonymizer11.noarch      0.2.1-1.rhel7            pgdg11           
[root@docker ~]#
[root@docker ~]#
[root@docker ~]# yum list postgres* | grep
anaconda-ks.cfg                     .bashrc                             .dbus/                              .pki/
.bash_history                       .cache/                             initial-setup-ks.cfg                .tcshrc
.bash_logout                        .config/                            .local/                             .viminfo
.bash_profile                       .cshrc                              pgdg-oraclelinux11-11-2.noarch.rpm  .xauth5hcDeF
[root@docker ~]# yum list postgres* | grep 11
postgresql-jdbc.noarch              42.2.5-1.rhel7.1         pgdg11           
postgresql-jdbc-javadoc.noarch      42.2.5-1.rhel7.1         pgdg11           
postgresql-unit11.x86_64            7.0-1.rhel7              pgdg11           
postgresql-unit11-debuginfo.x86_64  7.0-1.rhel7              pgdg11           
postgresql11.x86_64                 11.1-1PGDG.rhel7         pgdg11           
postgresql11-contrib.x86_64         11.1-1PGDG.rhel7         pgdg11           
postgresql11-debuginfo.x86_64       11.1-1PGDG.rhel7         pgdg11           
postgresql11-devel.x86_64           11.1-1PGDG.rhel7         pgdg11           
postgresql11-docs.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql11-libs.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql11-llvmjit.x86_64         11.1-1PGDG.rhel7         pgdg11           
postgresql11-odbc.x86_64            11.00.0000-1PGDG.rhel7   pgdg11           
postgresql11-plperl.x86_64          11.1-1PGDG.rhel7         pgdg11           
postgresql11-plpython.x86_64        11.1-1PGDG.rhel7         pgdg11           
postgresql11-pltcl.x86_64           11.1-1PGDG.rhel7         pgdg11           
postgresql11-server.x86_64          11.1-1PGDG.rhel7         pgdg11           
postgresql11-tcl.x86_64             2.4.0-2.rhel7.1          pgdg11           
postgresql11-test.x86_64            11.1-1PGDG.rhel7         pgdg11           
postgresql_anonymizer11.noarch      0.2.1-1.rhel7            pgdg11           
[root@docker ~]#
[root@docker ~]#
[root@docker ~]# yum install postgresql11-server
Loaded plugins: langpacks, ulninfo
Resolving Dependencies
--> Running transaction check
---> Package postgresql11-server.x86_64 0:11.1-1PGDG.rhel7 will be installed
--> Processing Dependency: postgresql11-libs(x86-64) = 11.1-1PGDG.rhel7 for package: postgresql11-server-11.1-1PGDG.rhel7.x86_64
--> Processing Dependency: postgresql11(x86-64) = 11.1-1PGDG.rhel7 for package: postgresql11-server-11.1-1PGDG.rhel7.x86_64
--> Processing Dependency: libpq.so.5()(64bit) for package: postgresql11-server-11.1-1PGDG.rhel7.x86_64
--> Running transaction check
---> Package postgresql11.x86_64 0:11.1-1PGDG.rhel7 will be installed
---> Package postgresql11-libs.x86_64 0:11.1-1PGDG.rhel7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

====================================================================================================================================================
 Package                                   Arch                         Version                                  Repository                    Size
====================================================================================================================================================
Installing:
 postgresql11-server                       x86_64                       11.1-1PGDG.rhel7                         pgdg11                       4.7 M
Installing for dependencies:
 postgresql11                              x86_64                       11.1-1PGDG.rhel7                         pgdg11                       1.6 M
 postgresql11-libs                         x86_64                       11.1-1PGDG.rhel7                         pgdg11                       359 k

Transaction Summary
====================================================================================================================================================
Install  1 Package (+2 Dependent packages)

Total download size: 6.7 M
Installed size: 29 M
Is this ok [y/d/N]: y
Downloading packages:
(1/3): postgresql11-libs-11.1-1PGDG.rhel7.x86_64.rpm                                                                         | 359 kB  00:00:04   
(2/3): postgresql11-11.1-1PGDG.rhel7.x86_64.rpm                                                                              | 1.6 MB  00:00:04   
(3/3): postgresql11-server-11.1-1PGDG.rhel7.x86_64.rpm                                                                       | 4.7 MB  00:00:02   
----------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                               974 kB/s | 6.7 MB  00:00:07   
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Warning: RPMDB altered outside of yum.
  Installing : postgresql11-libs-11.1-1PGDG.rhel7.x86_64                                                                                        1/3
  Installing : postgresql11-11.1-1PGDG.rhel7.x86_64                                                                                             2/3
  Installing : postgresql11-server-11.1-1PGDG.rhel7.x86_64                                                                                      3/3
  Verifying  : postgresql11-libs-11.1-1PGDG.rhel7.x86_64                                                                                        1/3
  Verifying  : postgresql11-11.1-1PGDG.rhel7.x86_64                                                                                             2/3
  Verifying  : postgresql11-server-11.1-1PGDG.rhel7.x86_64                                                                                      3/3

Installed:
  postgresql11-server.x86_64 0:11.1-1PGDG.rhel7                                                                                                   

Dependency Installed:
  postgresql11.x86_64 0:11.1-1PGDG.rhel7                                 postgresql11-libs.x86_64 0:11.1-1PGDG.rhel7                               

Complete!
[root@docker ~]#

In order to quickly download Oracle software from My Oracle Support (MOS) to your server or local host, you must have curl or wget installed.

Check these by using:

[oracle@test working]$ which curl
/usr/bin/curl
[oracle@test working]$ which wget
/usr/bin/wget




Now use following command from the operating system prompt to download orachk, opatch, any Oracle patch or any other software by using your MOS credentials.

Right click on the software link and copy the link e.g. For orachk , this is the link:

https://updates.oracle.com/Orion/Services/download/orachk_beta.zip?aru=21110110&patch_file=orachk_beta.zip

It's always a good idea to stop extracts after checking if there is any long running transaction in the database being captured. Failing to do so might later result in hung or unstable processes.





Use following command to check the extract:

GGSCI (test) 3> send e* status

Sending STATUS request to EXTRACT ext ...


EXTRACT ext (PID 16649)
  Current status: In recovery[1]: Processing data with empty data queue
  
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  
testsrv:/u05/ggate> grep -i bound dirrpt/ext.rpt 
Bounded Recovery Parameter:
2017-06-07 15:48:18  INFO    OGG-01639  BOUNDED RECOVERY:  ACTIVE: for object pool 2: p2628_Redo_Thread_2.
2017-06-07 15:48:18  INFO    OGG-01640  BOUNDED RECOVERY: recovery start XID: 129.15.2953694.  

-- And then Check RBA is moving with following commands
./ggsci 
info e*
lag e*

One extract got abended and wasn't able to start in Oracle Goldengate Version 12.2.0.1.160517 23194417_FBO. The redologs were present but extract was still abended and threw following error in the report file.

Error:

ERROR OGG-02037 Failed to retrieve the name of a missing Oracle redo log.

Solution:




The solution for this error is to unregister, register and then start the extract as follows:


GGSCI (test) 6> unregister extract ext database 2018-11-07 17:07:03 INFO OGG-01750 Successfully unregistered EXTRACT ext from database. GGSCI (test) 7> GGSCI (test) 7> register extract ext database 2018-11-07 17:07:56 INFO OGG-02003 Extract ESTATDEV successfully registered with database at SCN 1373637632014. GGSCI (test) 8> start extract ext

This post contains step by step instructions for creating an Ansible role acfssetup to setup Oracle ASM Cluster Filesystem (ACFS) on multiple nodes of a cluster. This assumes that Grid Infrastructure 12.1.0.2.0 is already installed on the nodes, and ASM is working fine. This also assumes that there already is Ansible installed on some controller host with ssh equivalency setup between root and Oracle users.




Step 1: Create directory structure for the role acfssetup:


$ cd /etc/ansible/roles
$ mkdir acfssetup
$ mkdir files handlers meta templates tasks vars

Step 2: Create the Tasks (/etc/ansible/roles/acfssetup/tasks/main.yml):

---

- name: Install ACFS/ADVM modules on the nodes
  become_user: "{{ superuser }}"
  environment: "{{ asm_instance }}"
  shell:"{ gi_home_path }}/bin/acfsroot install"
  tags:acfs

- name: Start and enable the ACFS modules on the nodes
  become_user: "{{ superuser }}"
  environment: "{{ asm_instance }}"
  shell:"{ gi_home_path }}/bin/acfsload start"
  shell:"{ gi_home_path }}/bin/acfsroot enable"
  tags:acfs
 
- name: As oracle user, create an ASM volume for ACFS on first node
  when: inventory_hostname in groups['node1']
  become_user: "{{ gi_owner }}"
  environment: "{{ asm_instance }}"
  shell:"{ gi_home_path }}/bin/asmcmd volcreate -G {{ asm_dg_name }} -s {{ acfs_vol_size }} {{ acfs_vol_name }}"
  shell:"{ gi_home_path }}/bin/asmcmd volinfo -G {{ asm_dg_name }} {{ acfs_vol_name }} | grep Device | sed 's/.*://'"
  register: {{ device_name }}
  tags:acfs

- name: As oracle user, create the filesystem on the volume which was just created
  become_user: "{{ gi_owner }}"
  environment: "{{ asm_instance }}"
  shell:"/sbin/mkfs -t acfs {{ device_name }}.stdout"
  tags:acfs

- name: As root, create an empty directory which will house the file system
  become_user: "{{ superuser }}"
  environment: "{{ asm_instance }}"
  shell:"mkdir -p /{{ acfs_mount_name }}/{{ acfs_vol_name }}; chown root:oinstall /{{ acfs_mount_name }}; chmod 770 /{{ acfs_mount_name }}; chown -R oracle:oinstall /{{ acfs_mount_name }}/{{ acfs_vol_name }}; chmod 775 /{{ acfs_mount_name }}/{{ acfs_vol_name }}"
  tags:acfs

- name: As root, setup the file system to be auto mounted by clusterware
  become_user: "{{ superuser }}"
  environment: "{{ asm_instance }}"
  shell:"{ gi_home_path }}/bin/srvctl add volume -volume {{ acfs_vol_name }} -diskgroup {{ asm_dg_name }} -device {{ device_name }}.stdout; { gi_home_path }}/bin/srvctl add filesystem -device {{ device_name }}.stdout -path {{ acfs_mount_name }}/{{ acfs_vol_name }} -diskgroup {{ asm_dg_name }} -user {{ gi_owner }} -fstype ACFS -description \"ACFS General Purpose Mount\""
  tags:acfs

  Step 3: Create the Variables (/etc/ansible/roles/acfssetup/vars/main.yml):

ver: "12.1.0.2.0"
superuser: root
asm_instance: +ASM
asm_dg_name: DATA
acfs_vol_name: ACFSVOL1
acfs_vol_size: 10G
acfs_mount_name: acfsmounts
device_name: default([])
gi_owner: oracle
gi_group: oinstall
gi_base_path: "/u01/app/oracle"
gi_home_path: "{{ gi_base_path }}/product/{{ ver |
regex_replace('^(.*)\\.(.*)\\.(.*)\\.(.*)$', '\\1.\\2.\\3') }}/grid"
gi_home_name: "OraGI{{ ver | regex_replace('^(.*)\\.(.*)\\.(.*)\\.(.*)$', '\\1\\2')}}"

Step 4: Configure Ansible host file (/etc/ansible/hosts)

node1 ansible_host=node1.foo.com
node2 ansible_host=node2.foo.com

Step 5: Create the skeleton Playbook (/etc/ansible/acfs.yml):

---
- hosts: all
become: true
roles:
- acfssetup

Step 6: Run the playbook

$ ansible-playbook acfs.yml

----- In Oracle 12.1.0.2, created the wallet by using below commands:

TEST$ orapki wallet create -wallet "/u01/app/oracle/admin/TEST/wallet" -pwd ****  -auto_login_local
Oracle PKI Tool : Version 12.1.0.2
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.


TEST$ mkstore -wrl "/u01/app/oracle/admin/TEST/wallet" -createCredential TEST2 sys ********
Oracle Secret Store Tool : Version 12.1.0.2
Copyright (c) 2004, 2014, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:
Create credential oracle.security.client.connect_string1

----- But when I logged into the database with sys user, the show user showed OPS$ORACLE user instead of sys:

TEST$ sqlplus /@TEST2

SQL*Plus: Release 12.1.0.2.0 Production on Thu Aug 9 13:09:38 2018

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Last Successful login time: Thu Aug 09 2018 03:18:20 -04:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options

SQL> sho user
USER is "OPS$ORACLE"
SQL>

----- So made following changes and it worked fine:

Put following entry in sqlnet.ora file:

SQLNET.WALLET_OVERRIDE = TRUE
The SQLNET.WALLET_OVERRIDE entry allows this method to override any existing OS authentication configuration.

and used mkstore to create the wallet:

TEST$  mkstore -wrl "/u01/app/oracle/admin/TEST/wallet" -createCredential TEST2 sys

I got paged for a goldengate extract lagging behind. Checked the extract configuration and it was normal extract and it seemed stuck without giving any error in the ggserr.log or anywhere else. It wasn't abended either and was in running state.


Tried stopping and restating it, but still it remained in running state while doing nothing and lag was increasing. So the issue was clearly outside of goldengate. Checked the database by starting from alert log and didn't see any errors there either.

Jumped into the database and ran some queries to see which sessions were active and what they were running. After going through various active sessions, turned out that few of them were doing long transactions over a dblink and these sessions were several hours old and seemed stuck. These sessions were also inducing widespread delay on the temp tablespace and were blocking other sessions. Due to undersized temp plus these stuck long running transactions, database performance was also slower than usual.

Ran a select statement over that dblink and it was very slow. Used tnsping to ping that database remotely and it returned with delay. Then used network commands like ping, tracert, etc to check network status and it all was pointing to delay in network.

Killed the long running transaction as it was going nowhere, and that eased the pressure on temp tablespace, which in return enabled extract to finish off the lag.

UUID stands for Universally Unique Identifier. I use UUID for my disk device, when I need to create and add disks for Oracle ASM, as UUID is independet of device name or mountpoint. So its always a good idea to include UUID of device in the fstab file in Linux.

So here is how to find the UUID of a device in Linux for Oracle ASM:




[root@bastion ~]$ ls -l /dev/disk/by-uuid
lrwxrwxrwx 1 root root 11 JAN 18 20:38 1101c254-0b92-42ca-b34a-6d283bd2d31b -> ../../sda2
lrwxrwxrwx 1 root root 11 JAN 18 20:38 11dc5104-C07b-4439-bdab-00a76fcb88df -> ../../sda1

HTH.

With ever changing pricing model and services, its hard to keep track of AWS costing.





If you want to check how much would it cost to have a certain AWS service, tailored to your requirement then use the following Simply Monthly Calculator from AWS.

AWS Price Calculator.

For most of production RDS databases , we normally have a related EC2 server to access that RDS database through tools like datapump, sqlplus etc.



RDS is great for point and click but if you want to run your own monitoring or other administration related scripts, you need to have an EC2 instance with AWS CLI installed. For example if you want to check the status of RDS instances or if you want to check if RDS snapshots happened or not today through some check and notify DBA through page or email, you can do that with the AWS CLI.

I will be writing and sharing some RDS related shell scripts using AWS CLI in coming days so stay tuned. 

Following are steps to move a datafile from one ASM diskgroup to another diskgroup in the same ASM instance:




For this example, let's suppose the full path of datafile to be moved is +DATA/test/datafile/test.22.121357823 and datafile number is 11.

Step 1: From RMAN, put datafile 11 offline:

SQL "ALTER DATABASE DATAFILE ''+DATA/test/datafile/test.22.121357823'' OFFLINE";

Step 2: Backup Datafile 11 to Copy using RMAN:

$ rman target /
BACKUP AS COPY DATAFILE 11 FORMAT '+DATA_NEW';

--- Make note the path and name of the generated datafile copy.

Step 3: From RMAN, switch datafile 11 to copy:

SWITCH DATAFILE "+DATA/test/datafile/test.22.121357823" TO COPY;

Step 4: From RMAN, Recover Datafile 11:

RECOVER DATAFILE 11;

Step 5: From RMAN, put datafiles online:

SQL "ALTER DATABASE DATAFILE ''+DATA_NEW/'' ONLINE";

Step 6: From SQLPlus, verify if datafile 11 was correctly switched and was online:

sqlplus / as sysdba
SQL> select file_id,file_name,online_status from dba_data_files where file_id in (11);

Look at the following picture displayed at Oracle's official website here, and you would forgive anyone who would naively believe that the Oracle 18c is a self-driving, autonomous database.





Now, in above mentioned article after reading the title and the first paragraph, one still maintains the notion that Oracle 18c is autonomous and self-driving database. Its only after reading second paragraph carefully, one should understand the true picture.

The second paragraph in that article clearly says that self-driving and autonomous is Oracle Autonomous Database Cloud  powered by Oracle 18c database and not the Oracle database 18c itself.

So this autonomy is about cloud service and not about the RDBMS. This cloud service could very well run on Oracle 12c and say the same or any other version for that matter. DBA's role in such managed database cloud services is still nominal. So if its not on the cloud then DBA's role is more challenging then before as every new version is packed with new features.

Occasionally, In Oracle 12c database, you may get ORA-00240: control file enqueue held for more than 120 seconds  error in the alert log file.


Well, as this error contains the word control file so it looks scary but if you are getting it infrequently and the instance stays up and running then there is no need to worry and this can be ignored as a fleeting glitch.

But if it starts happening too often and worst case if it hangs or crashes the instance then more than likely its  a bug and you need to apply either the latest PSU or any one-off patch available from Oracle support after raising SR.

There have been some occurances where this error occured due to high number of sessions and conflicting with the ulimit of the operating system resulting in hanging of ASM and RDBMS. Some time it could be due to shared pool latch contention as per few MOS documents.

So if its rare, then ignore it and move on with the life as there are other plenty of things to worry about. If its frequent and a show-stopper then by all means raise a SEV-1 SR with Oracle support as soon as possible.

More often than not, database administrators around the technologies have to fight out high load on their databases. It could be ad hoc queries, urgent reports, overflown jobs, or simply high frequency and volume of queries by the end users.

DBAs try their best to do a generous capacity planning to ensure optimal response time and throughput for the end users. There are various scenarios where it becomes very hard to predict the demand. Storage and processing needs in case of unpredictable load are hard to foretell in advance.





Cloud computing offers the promise of unmatched scalability for processing and storage needs. Amazon AWS has introduced a new service which gets closer to that ultimate scalability. Amazon Aurora is hosted relational database service by AWS. You set your instance size and storage need while setting Aurora up. If your processing requirements change, you change your instance size and if you need more read throughput you add more read replicas.

But that is good for the loads we know about and can more ore less predict. What about the loads which appear out of blue? May be for a blogging site, where some post has suddenly gone viral and it has started getting million of views instead of hundreds? And then the traffic disappears after some time suddenly just like it appeared out of nowhere and may be after some days it happens for some another post?

In this case if you are running Amazon Aurora, it would be fairly expensive to just increase the instance size or read replicas in the anticipation that some traffic burst would come. It might not, but then it might.

In front of this uncertainty, enters Amazon Aurora Serverless. With this Serverless Aurora, you don't select your instance size. You simply specify an endpoint and then all the queries are routed to that endpoint. Behind that endpoint lies a a warm proxy fleet of database capacity which can scale as per your requirements within 5 seconds.

It's all on-demand and ideal for transient spiky loads. What's more sweet is that billing is on second by second basis and deals in Aurora capacity units and minimum is 1-minute for each newly address resource.