The following question in the Oracle Groundbreakers Developer Community forum made me investigate on how to change the session timeout in the Oracle Cloud console. Have a look, it is still for some reason unanswered:
For those who use Oracle Cloud Infrastructure on daily basis, they know that the default session timeout is 480 minutes although in my case it is an hour – so often after you switch to the OCI tab, you see the following screen:
Here is the way how you can change it to a longer period with 32767 minutes being the maximum allowed.
Step 1: Open the Service User Console
Step 2: Open the Identity Cloud Service Admin Console:
Step 3: From the Dashboard, choose “Settings” and from there “Session Settings”:
Step 4: Set the “Session Duration” to a longer period of time:
Step 5: Saving the settings to the new value: I chose the maximum which is 32767 minutes:
Two very different in nature but equality useful features are now available in the Oracle Autonomous Database:
SQL Tracing in Autonomous Database
Cross-Region Autonomous Data Guard in ADB-S
Here is how to enable and use them:
SQL Trace in ADB:
You need first a standard bucket as SQL tracing files are only supported with buckets created in the standard storage tier. Also, create a token (you can have at most 2 tokens) and do not use your OCI password when creating the credentials.
Next, you have to create a credential for your Cloud Object Storage account. Note the full username below – do not simply use the one with what you login to the console.
Afterwards, set the init.ora parameters DEFAULT_LOGGING_BUCKET to specify the Cloud Object Storage URL for a bucket for SQL trace files:
SET DEFINE OFF;
ALTER DATABASE PROPERTY SET
DEFAULT_LOGGING_BUCKET = 'https://objectstorage.eu-frankfurt-1.oraclecloud.com/n/juliandon/b/adbkofa/o/';
Database altered.
Next, specify the credentials to access the Cloud Object Storage. Note that although I am doing this as the ADMIN user, I still have to prefix the credential with ADMIN. Otherwise, you get an error message.
ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'ADMIN.JULIANDON_CREDENTIAL';
Database altered.
Before we can enable SQL trace, we configure the database to save SQL Trace files:
exec DBMS_SESSION.SET_IDENTIFIER('sqltrace_jd');
PL/SQL procedure successfully completed.
exec DBMS_APPLICATION_INFO.SET_MODULE('module_jmd', null);
PL/SQL procedure successfully completed.
ALTER SESSION SET SQL_TRACE = TRUE;
After running the SQLs, disable SQL tracing so that the collected data for the session is written to a table in your session and to a trace file in the bucket you configured when you set up SQL trace.
ALTER SESSION SET SQL_TRACE = FALSE;
ALTER DATABASE PROPERTY SET DEFAULT_LOGGING_BUCKET = '';
The SQL Trace facility writes the trace data collected in the session to Cloud Object Store in the following format:
When you enable SQL Tracing, the same trace information that is saved to the trace file on Cloud Object Store is available in the SESSION_CLOUD_TRACE view in the session where the tracing was enabled.
SELECT trace FROM SESSION_CLOUD_TRACE ORDER BY row_number;
After you close the session, the data is no longer available in SESSION_CLOUD_TRACE.
DESC SESSION_CLOUD_TRACE
Name Null? Type
---------- ----- ------------------------------
ROW_NUMBER NUMBER
TRACE VARCHAR2(32767)
Autonomous Data Guard provides a standby database instance in a different availability domain in the same region or in a standby database instance in different region.
If you create the standby database in the current/local region and if the primary instance becomes unavailable – the Autonomous Database automatically switches the role of the standby database to primary and begins recreating a new standby database.
ADB currently supports up to 2 standby databases – a local one in the same-region and an additional one which is remote – called cross-region.
So, with the new cross-region standby database, you can perform a manual failover to the standby database if the current region goes down.
Note that each region has one or a few nearby paired regions in which a remote standby may be created. As you can see from the screenshot above my tenancy in Frankfurt is subscribed to 3 remote regions in which I can create a remote standby.
It is important to know that ADB-S does not allow us access to the standby databases but after a switchover or failover, the database wallet downloaded in the primary database region can be used in the remote region.
It is extremely simple to manually switchover to the other region – in my case from Frankfurt to Zurich, just with a click of a button:
Julian is the Global Database Lead of Accenture. His primary responsibility is managing and leading the Global Database Platforms which includes Autonomous Cloud, IaaS, PaaS, Database Services, Engineered Systems, Security and all other areas falling under Database Engineering (all DB brands). He is also the Global Managing Director of the ... Continue reading →