The new CS_SESSION package and DB_NOTIFICATIONS view in the Autonomous Database

Two new objects have been recently introduced in the Oracle Autonomous Database on Shared Exadata Infrastructure.

1. The first one is the CS_SESSION package.

When you open a connection to the Autonomous Database, that session is assigned a consumer group. But consumer groups affect the concurrency and the DOP (degree of parallelism). HIGH service is run in parallel while LOW service runs in serial. So for example, if you have a PL/SQL procedure or function that has to execute statements in the same session with changing consumer groups, the way is to use the new CS_SESSION.SERVICE_NAME procedure.

The number of concurrent statements run in the database depends on 2 factors: the type of the service name and the numbers of the Oracle CPUs provisioned for the ADB:

The new package CS_SESSION contains only one procedure: SERVICE_NAME. My current version is 19.14, I am not sure if the package/procedure is included in all lower RUs. Most likely it is.

The valid values accepted as an IN parameter are: HIGH, MEDIUM, LOW, TP and TPURGENT.

After running the procedure, Oracle does not reset any session attributes. Anything the user set for their session before calling this procedure will continue as-is. 

The ADMIN user is granted EXECUTE privilege on CS_SESSION with GRANT OPTION. The privilege is also granted to DWROLE without the GRANT OPTION.

Here is how to change the consumer group from LOW to TPURGENT:

You might get the following error:

ORA-02097: parameter cannot be modified because specified value is invalid ORA-01031: insufficient privileges ORA-06512: at “C##CLOUD$SERVICE.CS_SESSION”, line 142

Note there is an open bug for this.

You can create an AFTER SET CONTAINER trigger if you would like to limit the values a user can set for the consumer group session. You might not want that all users can set to TPURGENT but allow them go with TP only.

2. The second new object is the DB_NOTIFICATIONS view which stores information about maintenance status notifications and timezone version upgrade notifications for the ADB instance. Let us describe the view

and check what is in it:

As we can see there was a patch run on the data dictionary and there is another maintenance scheduled for the 19th of January.

3. Good to know that we can now use GitHub Raw URLs with DBMS_CLOUD APIs to access source files that reside on a GitHub Repository.

4. Also, the DBMS_PIPE package is now available in the Autonomous Database.

Moving Autonomous Databases across regions

With the new OCI regions, we might want to move our databases to a closer location – in my case moving my databases from Frankfurt to Stockholm.

First what comes to mind is to enable Autonomous Data Guard and then switch over. However, you need a paired region – we cannot create a standby database just anywhere:

The list of Autonomous Data Guard Paired Regions shows that for each Source Region, we have 1-4 Paired Regions.

You need to be subscribed to a region before it can appear on the list and use it. And note: once you subscribe, there is no unsubscribe! You will need to apply for a limit increase.

I am told that soon, once a good standing payment history has been established, you will be eligible for unlimited regions. 

Another option is simply to create a clone:

Note that if you are using a clone from a backup, you cannot have the clone in another region, no idea why not! As you can see from the screenshot below, I am not getting a drop down list of regions:

So, let us create the database clone in Stockholm from the current AEG database running in Frankfurt:

Once the database is cloned, you can optionally terminate the copy in Frankfurt. But do not do it before you have verified the new clone as you might get an (unknown) error, something like this:

In case you do not want to deal with support, just create a new database and move the data with Data Pump.

My home region is Germany Central (Frankfurt). So am I able to change now my home region to Sweden Central (Stockholm) instead of Germany Central (Frankfurt)? Alas, this is not possible. Not yet at least.

According to the Metalink document Change Home Region in OCI console (Doc ID 2389905.1), the home region of the tenancy is fixed at creation time and cannot be moved. If you still wish to have the region changed, the only way to get it done would be to re-create the tenancy. That would mean removal of the current tenancy with all its resources and creating a new one.

Having the primary database in one region and a standby database in another is good practice in terms of DR. Even more complex scenarios are available. How about having a sharded Oracle Database spread among OCI, AWS and Azure? Possible but I would avoid such a complexity.