Sometimes its the little things that annoy me the most. OK, maybe its more often than sometimes.
In today’s episode of annoying things, I was looking for the latest Oracle database and grid infrastructure gold images for Exadata so I can update my databases to Oracle AI Database 26ai (more on that in another post).
As always, I go to the following MOS notes – 888828.1, and 888.1 – to get the desired information.
Which give me the specific patches I need to download. (888828.1 first, followed by 888.1)
But here’s the thing – I want the Database and GI Gold Image Clone files for Exadata so I can use them with OEDACLI to install and update my VM clusters.
In MOS, to find these you can search for “DB SOFTWARE CLONE” or “‘GI SOFTWARE CLONE” and do some digging to find what you’re looking for.
But the easiest option to find this information is to use OEDA itself.
Then unzip it to a location of your choosing, fire up the Web UI and walk through creating a configuration, or upload and update an existing configuration, which will give you the desired information in the installation report at the end!
Simple right. Sure – but its actually even easier than this.
OEDACLI has a great little feature which gives you this same information, namely the patches you need to download, in two simple commands.
Again, after downloading the latest OEDA release, start oedacli from the command line. You don’t need to provide a configuration file.
./oedacli
Then, use the ‘list requiredfiles’ command and pass in the DB or GI versions you want information about.
So for the DB, I want to grab patch 38455285, and for GI I want patch 38455288.
So what was annoying me about that? My own memory! This neat feature has been around since the around 2017 (if not earlier), but somewhere along the way I forgot about it and started doing things the hard way again…
Oh, and while we still have oedacli running, if you want to know what software versions are supported on your generation of Exadata, the LIST SOFTWAREVERSIONS command is really helpful.
oedacli> list softwareversions where type=X8M
GI Versions for X8M
11.2.0.4.210119
12.1.0.2.220719
12.2.0.1.220118
18.14.0.0.210420
19.29.0.0.251021, 19.28.0.0.250715, 19.27.0.0.250415, 19.26.0.0.250121
23.26.0.0.0, 23.9.0.25.07, 23.8.0.25.04, 23.7.0.25.01
Recommended GI version: 23.26.0.0.0
DB Versions for X8M
11.2.0.4.210119
12.1.0.2.220719
12.2.0.1.220118
18.14.0.0.210420
19.29.0.0.251021, 19.28.0.0.250715, 19.27.0.0.250415, 19.26.0.0.250121
23.26.0.0.0, 23.9.0.25.07, 23.8.0.25.04, 23.7.0.25.01
Recommended DB version: 23.26.0.0.0
Make sure you have the appropriate support in place for any versions earlier than 19c.
And that’s it – the easiest way to get the patch numbers for the Gold Image Clones used by OEDA and Exadata to deploy and update Oracle Database and Grid Infrastructure!
Want to see how quick it is to create a clone of an Oracle 23ai PDB on Exadata Exascale?
First a little background information.
I have a “simple” database in the example, with a PDB – named DEMOPDB1.
show pdbs
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
_________ ___________ _____________ _____________
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
4 DEMOPDB1 READ WRITE NO
It’s approximately 2.4 TB in size (temp excluded).
SQL> select p.name, sum(f.bytes)/1024/1024/1024 as total_gb
2 from v$pdbs p, v$datafile f
3 where p.con_id = f.con_id
4* group by p.name;
NAME TOTAL_GB
___________ ________________________
PDB$SEED 10.625396728515625
PDB1 14.718536376953125
DEMOPDB1 2403.8817901611328125
To create a clone of this PDB on Exascale, all we need to do is
SQL> set timing on; <- so you can see how fast it is
SQL> create pluggable database demopdb2 from demopdb1 snapshot copy;
Pluggable database DEMOPDB2 created.
Elapsed: 00:00:11.105 <- ~2.4 TB in under 12 seconds!!
The keywords ‘SNAPSHOT COPY’ are important here. They’re instructing the database to use the space-efficient, thin-provisioned, redirect-on-write capabilities of Exascale to create
Then, we’ll open it up.
SQL> alter pluggable database DEMOPDB2 open instances=all;
Pluggable database DEMOPDB2 altered.
Elapsed: 00:00:10.897 <- opening the PDB on 2 instances in this case
Check the size of the new PDB – spoiler alert, its the same size as the PDB I was cloning!
SQL> select p.name, sum(f.bytes)/1024/1024/1024 as total_gb
2 from v$pdbs p, v$datafile f
3 where p.con_id = f.con_id
4* group by p.name;
NAME TOTAL_GB
___________ ________________________
PDB$SEED 10.625396728515625
PDB1 14.718536376953125
DEMOPDB1 2403.8817901611328125
DEMOPDB2 2403.8817901611328125 <- new PDB!
And that’s it – less than 30 seconds and you have a thin clone of a PDB.
I was recently playing with the new AI Vector Search capabilities of Database 23ai, when I did something a little daft.
Without really thinking about what I was doing, I increased the memory allocated to vector_memory_size. “Ok” you say, “Whats wrong with that?” At face value nothing, I changed a parameter. But as I didn’t think about the any of the other memory parameters, like sga_max_size and sga_max_target, I set myself up for an inevitable problem if I restarted the database, or the VMs I was using were restarted.
And restart the database (and the VMs) I did – or tried.
And restart the database did not.
Without worrying about how I messed up, lets cover how I got out of this pickle.
First, as the title indicates, I’m working on an Exadata that has been deployed with the awesome (if I do say so myself) Exascale technology. You can check out more about Exascale on the Exadata PM blog. For now, know that at its core is a new decoupled storage management system that manages storage resources globally, as in for many database or VM clusters, rather than cluster-by-cluster. It has similarities to ASM, but introduces a ton of new capabilities including resource pooling, and very cool database instant snapshot and cloning features. More on those another time. Back to my “broken” database.
As my database won’t start – not even in mount mode – I can’t easily update the vector_memory_size parameter. So I need to do the following:
Extract the spfile from Exascale as a text file
Remove or change the vector_memory_size parameter
Create an spfile from the edited text file
Start the database
Exascale aside, I sure most if not all DBA’s have had to do this at some point in their careers.
Step 1 – get the spfile!
SQL*Plus and sqlcl make this easy. Simply fire up your chosen utility and
SQL> create pfile='/tmp/pfile.ora' from spfile;
That gets us our parameters out of Exascale into an easily editable text file.
Step 2 – edit the pfile!
Again, this is pretty simple. Start your text editor of choice, e.g. vi, emacs, nano, pico, etc, and make the required changes to the file you created in the last step.
In my case, rather than remove or downsizing the memory allocation for vector_memory_size, I’m going to up-size my SGA.
For the sake of comparison, this was the SGA size before I shotdown the database and realized what I’d done.
SQL> show sga
Total System Global Area 6439969072 bytes
Fixed Size 5439792 bytes
Variable Size 2030043136 bytes
Database Buffers 2248146944 bytes
Redo Buffers 8855552 bytes
In-Memory Area 2147483648 bytes
Vector Memory Area 2147483648 bytes
Step 3 – (re)create the spfile from the edited pfile!
Now we have a pfile, we need to re-create the spfile in Exascale so both instances in my cluster can access it.
First, we’ll create an spfile from the pfile in SQL*Plus or sqlcl
SQL> create spfile from pfile='/tmp/pfile.ora'
This will create an spfile in the $ORACLE_HOME/dbs directory of the database VM you are currently on. In my case, its called $ORACLE_HOME/dbs/spfilec8db12.ora
$ ls -al $ORACLE_HOME/dbs/spfilec8db12.ora
-rw-r----- 1 oracle dba 8704 May 27 22:12 /u01/app/oracle/product/23.7.0.25/dbhome_1/dbs/spfilec8db12.ora
Next, we need to backup the existing spfile. I may be a Product Manager these days, but good old DBA instincts are hard to suppress.
First, lets get the location of our databases spfile using srvctl.
XSH includes a cp command that allows us to copy files in and out of Exascale storage. ASM has a similar capability.
Using XSH, we’ll copy our file current spfile to a safe location.
$ xsh cp @exapm13050608vault/EXAPM13050608-82B1CA80638E4F86BF2E4B3EABC7B6E7/C8DB1/PARAMETERFILE/spfile.OMF.628AA9E0 /tmp
$ ls -al spfile.OMF.628AA9E0
-rw-rw---- 1 oracle oinstall 8704 May 27 22:15 spfile.OMF.628AA9E0
Now we can copy our new spfile back into Exascale using XSH. Note in the command below, tell XSH that its copying in an ‘init‘ file with the --ftype attribute.
$ xsh cp --ftype init $ORACLE_HOME/dbs/spfilec8db12.ora @exapm13050608vault/EXAPM13050608-82B1CA80638E4F86BF2E4B3EABC7B6E7/C8DB1/PARAMETERFILE/spfile.OMF.628AA9E0
$ xsh ls -l @exapm13050608vault/EXAPM13050608-82B1CA80638E4F86BF2E4B3EABC7B6E7/C8DB1/PARAMETERFILE/spfile.OMF.628AA9E0
8704 Mar 10 15:24:05 2025 @exapm13050608vault/EXAPM13050608-82B1CA80638E4F86BF2E4B3EABC7B6E7/C8DB1/PARAMETERFILE/spfile.OMF.628AA9E0
Step 4 – restart the database!
Finally, use srvctl to restart the database
$ srvctl start database -db C8DB1
Success! The database is back up and running.
Comparing the SGA now with the earlier one, you can see I added 4 GB to the sga_max_size and sga_target being the total to 10 GB.
SQL> show sga
Total System Global Area 10736573488 bytes
Fixed Size 7076912 bytes
Variable Size 2516582400 bytes
Database Buffers 3909091328 bytes
Redo Buffers 8855552 bytes
In-Memory Area 2147483648 bytes
Vector Memory Area 2147483648 bytes
And that’s it. You can copy spfiles in and out of Exascale. In reality, you can copy many more file types in and out – check out the XSH – the Exascale Shell command reference for all the details.
While I still have access to an ExaCS, I wanted to check out the new feature available in the OCI console to patch an Oracle DB by moving it from one home to another (ie 19.4 to 19.6, not 12.2.0.1 to 19.x…).
In reality, you might want to create an older home so you can restore a backup of a database, test patching procedures, performance and stability (using Real Application Testing) – to name a few ideas.
Sounds all well and good, but I currently have a 19.6 DB, running on a 19.6 GI/ASM stack and am not in the position to patch to 19.7 at the moment. So what can I do?
So we need to create a new Oracle Home – one with an RU (release update) of lower than 19.6.
In the console, when I hit “Create Database Home”, it gives me the below options – note that they do not list the specific Release Update or Bundle Patch version.
Create Database Home dialog
As I mentioned, this is an ExaCS instance I created with 19.6 GI/ASM and 19.6 Database (currently the default RU version on this particular instance).
What I need to do is download an earlier RU for ExaCS, activate it as the default, and then create a new Oracle Home either through the above console or using OCI CLI. So lets look at whats already on the ExaCS instance.
Log on to one of the nodes as opc and sudo su - (sudo to root)
We’re then going to fire up the dbaascli tool to check work with the ExaCS environment
[root@exacs-asxyq1 ~]# dbaascli
DBAAS CLI version 19.4.4.0.0DBGI
DBAAS>
First, lets check what Database Home images have already been downloaded to the ACFS software library using the dbimage list command
DBAAS> dbimage list
Executing command dbimage list
INFO : Log file => /var/opt/oracle/log/dbimage_list/dbimage_list_2020-05-12_14:31:36.56429682748.log
INFO : dbimage fixup executed.
################## List of Available dbimages on acfs ###################
-JAN2020 (For DB Versions 11204, 12102, 12201, 18000, 19000) => 24G consumed on acfs
-OCT2019 (For DB Versions 19000) => 4.0G consumed on acfs
######################## Default BP on acfs #############################
-11204 => JAN2020
-12102 => JAN2020
-12201 => JAN2020
-18000 => JAN2020
-19000 => JAN2020
################## Acfs disk space usage ######################
Filesystem Size Used Avail Use% Mounted on
/dev/asm/acfsvol01-377 560G 45G 516G 8% /acfs01
################# /var/opt/oracle/dbaas_acfs/dbnid space usage ###################
29G
As you can see from lines 9 & 10, I currently have Oracle Home images for the JAN2020 RU/BPs for versions 11.2, 12.1, 12.2, 18c & 19c. I also have the OCT2019 RU for 19c already downloaded.
Also note that the current default RU/BPs for each release are listed as:
11204 => JAN2020
12102 => JAN2020
12201 => JAN2020
18000 => JAN2020
19000 => JAN2020
Now lets check what Oracle Home images are available to download using the cswlib list command.
DBAAS>cswlib list
Executing command cswlib list
INFO : Log file => /var/opt/oracle/log/list/list_2020-05-12_14:25:49.32901082748.log
INFO : dbimage fixup executed.
############ List of Available BP #############
-APR2017 (For DB Versions 12201 12102 11204)
-JAN2018 (For DB Versions 12201 12102 11204)
-APR2018 (For DB Versions 12201 12102 11204)
-JUL2018 (For DB Versions 18000 12201 12102 11204)
-OCT2018 (For DB Versions 18000 12201 12102 11204)
-JAN2019 (For DB Versions 18000 12201 12102 11204)
-APR2019 (For DB Versions 18000 12201 12102 11204 19000)
-JUL2019 (For DB Versions 18000 12201 12102 11204 19000)
-OCT2019 (For DB Versions 18000 12201 12102 11204 19000)
-JAN2020 (For DB Versions 18000 12201 12102 11204 19000)
############ List of Available NONCDB BP #######
-APR2018 (For DB Versions 12201 12102)
-JAN2019 (For DB Versions 12201 12102)
-APR2019 (For DB Versions 12201 12102)
-JUL2019 (For DB Versions 12201 12102)
-OCT2019 (For DB Versions 12102 19000)
-JAN2020 (For DB Versions 12102 19000)
UPDATE – 29th September 2020 – dbaascli cswlib list|download now only allows you to operate on the current, and two most recent RUs – ie, N, N-1 and N-2. See the screen grab below
DBAAS>cswlib list
Executing command cswlib list
INFO : Log file => /var/opt/oracle/log/list/list_2020-09-29_15:08:33.757113220980.log
INFO : dbimage fixup executed.
############ List of Available BP #############
-JAN2020 (For DB Versions 18000 12201 12102 11204 19000)
-APR2020 (For DB Versions 18000 12201 12102 11204 19000)
-JUL2020 (For DB Versions 18000 12201 12102 11204 19000)
############ List of Available NONCDB BP #######
-JAN2020 (For DB Versions 12102 19000)
-APR2020 (For DB Versions 12102 19000)
-JUL2020 (For DB Versions 12102 19000)
Without going through each matrix in detail, you can see that there are two kinds of images – CDB (the top list) and NONCDB (second list, and for use during migrations to OCI).
DBAAS>cswlib download --version 19000 --bp APR2019
Executing command cswlib download --version 19000 --bp APR2019
INFO : Download running for BP APR2019 and version 19000, it may take few mins...
INFO: CSWLIB update APR2019 db image bits
INFO: Log file is: /var/opt/oracle/log/misc/cswlib/cswlib_2020-05-12_14:41:33.397675181223.log
INFO : dbimage fixup executed.
INFO: CSWLIB update_bits of APR2019 19000 succeded !
INFO: dbaascli dbimage activateBP needs to be run to make the downloaded BP the “default” !
The least amount of information needed to download the RU/BP in question is the version & the BP name. In our case, we’re working with Oracle 19c (19000) and the ARP2019 RU.
Once this has been downloaded you can rerun dbimage list to check it is available on the ExaCS. Also note that the current default is has not been changed as part of the download process.
DBAAS>dbimage list
Executing command dbimage list
INFO : Log file => /var/opt/oracle/log/dbimage_list/dbimage_list_2020-05-12_15:59:24.01757782748.log
INFO : dbimage fixup executed.
################## List of Available dbimages on acfs ###################
-JAN2020 (For DB Versions 11204, 12102, 12201, 18000, 19000) => 24G consumed on acfs
-OCT2019 (For DB Versions 19000) => 4.0G consumed on acfs
-APR2019 (For DB Versions 19000) => 3.6G consumed on acfs
######################## Default BP on acfs #############################
-11204 => JAN2020
-12102 => JAN2020
-12201 => JAN2020
-18000 => JAN2020
-19000 => JAN2020
################## Acfs disk space usage ######################
Filesystem Size Used Avail Use% Mounted on
/dev/asm/acfsvol01-377 560G 49G 512G 9% /acfs01
################# /var/opt/oracle/dbaas_acfs/dbnid space usage ###################
32G
Next, we need to Activate the ARP2019 image as the default so we can then kick off the deployment of the home to the two ExaCS compute nodes. We do this using the dbimage activateBP command.
DBAAS>dbimage activateBP --version 19000 --bp APR2019
Executing command dbimage activateBP --version 19000 --bp APR2019
INFO : Log file is => /var/opt/oracle/log/dbimage_activateBP/dbimage_activateBP_2020-05-12_16:01:50.51664582748.log
INFO : dbimage fixup executed.
INFO : activateBP completed
Checking the dbimage list again, we can see the APR2019 image is now the default for 19000
DBAAS>dbimage list
Executing command dbimage list
...
snipped for brevity
...
######################## Default BP on acfs #############################
-11204 => JAN2020
-12102 => JAN2020
-12201 => JAN2020
-18000 => JAN2020
-19000 => APR2019
...
Now that we have activated to APR2019 RU, we can deploy the home. Unfortunately (or maybe fortunately) this is not done through the dbaascli. Instead, we can use either the OCI browser console or using the OCI CLI. Lets use the browser console.
Navigate to your ExaCS -> Database Homes and click Create Database Home.
ExaCS – Create Database Home
As shown above, when you create a new Database on the ExaCS, you choose the major database version, not the RU. We’ll choose 19c – given thats what we downloaded.
Once you’ve give the home a name (or used the auto-generated one). Press Create.
Complete
Once created, you can see the Database Home Path and the Database Version. Note that it takes a little while for the console to reflect the actual version – in this case it will reflect 19.3.0.0.
We can check the version before proceeding by running opatch lsinventory from the newly created Database Home (after setting the ORACLE_HOME accordingly).
[oracle@exacs-asxyq1 ~]$ export ORACLE_HOME=/u02/app/oracle/product/19.0.0.0/dbhome_3
[oracle@exacs-asxyq1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.17
Copyright (c) 2020, Oracle Corporation. All rights reserved.
Oracle Home : /u02/app/oracle/product/19.0.0.0/dbhome_3
Central Inventory : /u01/app/oraInventory
from : /u02/app/oracle/product/19.0.0.0/dbhome_3/oraInst.loc
OPatch version : 12.2.0.1.17
OUI version : 12.2.0.7.0
Log file location : /u02/app/oracle/product/19.0.0.0/dbhome_3/cfgtoollogs/opatch/opatch2020-05-12_17-03-26PM_1.log
Lsinventory Output file location : /u02/app/oracle/product/19.0.0.0/dbhome_3/cfgtoollogs/opatch/lsinv/lsinventory2020-05-12_17-03-26PM.txt
--------------------------------------------------------------------------------
Local Machine Information::
Hostname: exacs-asxyq1.exacsclient.suncorpmelvcn.oraclevcn.com
ARU platform id: 226
ARU platform description:: Linux x86-64
Installed Top-level Products (1):
Oracle Database 19c 19.0.0.0.0
There are 1 products installed in this Oracle Home.
Interim patches (3) :
Patch 29548437 : applied on Sat Apr 20 07:53:25 AEST 2019
Unique Patch ID: 22861714
Patch description: "OJVM RELEASE UPDATE: 19.3.0.0.190416 (29548437)"
Created on 11 Apr 2019, 02:24:07 hrs PST8PDT
Bugs fixed:
29540327, 29254623, 29445548
Patch 29585399 : applied on Thu Apr 18 17:21:33 AEST 2019
Unique Patch ID: 22840393
Patch description: "OCW RELEASE UPDATE 19.3.0.0.0 (29585399)"
Created on 9 Apr 2019, 19:12:47 hrs PST8PDT
Bugs fixed:
SNIPPED
Patch 29517242 : applied on Thu Apr 18 17:21:17 AEST 2019
Unique Patch ID: 22862832
Patch description: "Database Release Update : 19.3.0.0.190416 (29517242)"
Created on 17 Apr 2019, 23:27:10 hrs PST8PDT
SNIPPED
--------------------------------------------------------------------------------
OPatch succeeded.
Lets create our database now. Press Create Database and fill in the subsequent dialog as you see fit. Perhaps something like the following:
Create Database
I also enabled Automatic Backups with a 7 Day Retention Period
Once the database has been created (and the auto backup finished) you’ll see your database is now available and ready to go. Note again that it will take a little while for the console to reflect that the database version is 19.3.0.0.
Once you have the above done, you can then proceed to create an ExaCS. You could do this through the Web Console, but when I was presented with what I assume is a bug in the console, I decided to give the CLI a try.
Before executing the CLI, you need to create two (2) files:
A JSON formatted file that has the create_db_system payload
a file referenced in the main file that contains the SSH public key pair(s) you want to associate with the ExaCS instance
An example (based off the file I used) and explanation follows – you can get the json file from here:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ENTERPRISE_EDITION_EXTREME_PERFORMANCE is the only option if you're creating an ExaCS
dbName
dbname
Database name for initial DB
dbVersion
LATEST
Database (and therefore ASM/GI) version. I suggest you go with latest. You can then create new DB homes of earlier versions (back to 11.2). This gives you the greatest flexibility.
dbWorkload
OLTP
Is the DB an OLTP or DSS geared DB?
diskRedundancy
HIGH
HIGH ASM disk redundnacy is the only option for ExaCS
displayName
console_display_name
OCI Console Display Name
domain
client_subnet_domain
The domain name for the ExaCS Client network. Used to fully qualify host and SCAN addresses
hostname
hostname_prefix
Hostname prefix – ie 1-8 will be appended depending on the ExaCS Shape
licenseModel
BRING_YOUR_OWN_LICENSE
Are you using existing licenses or are you going LICENSE_INCLUDED?
nodeCount
0
For ExaCS this will be 0 – the number of nodes is determined by the shape.
pdbName
pdb1
The initial PDB name
shape
Exadata.Base.48
This is the ExaCS Shape – eg Exadata.Full3.400 or Exadata.Quarter2.92
sparseDiskgroup
true
Do you want to allocate some space to create/use sparse clones?
sshAuthorizedKeysFile
./keys.txt
Reference to a file with the SSH Public keys you want added to the compute nodes
Once you’ve updated the json file, and created a file for your ssh keys, you can run the following from your OS command line
oci db system launch --from-json file://create_exacs_ocicli.json
ExaCS will take a while to create – its doing a fair amount of work – so at this point, grab a coffee (or dinner & a movie depending on the time of day) and keep an eye on the progress through the OCI Console.
This guide walks you through creating an Oracle 18c Database System in Oracle Cloud Infrastructure (OCI).
Note: I am assuming that you have already created all the necessary networking components in your OCI tenancy.
OCI Home Page
Starting from the OCI Home page, hit the Menu link in the top left-hand corner, and the select “Bare Metal, VM, and Exadata” under the Database heading.
Check you’re in the right compartment
Hit the blue “Launch DB System” button and fill in the form and press “Launch DB System” at the bottom
After you hit “Launch DB System”, the console will report the system is provisioning
Database system being provisioned
Time to grab a cuppa or lunch and leave this to run for a while. You’ll know when its done when the orange box with “DBS” in it goes a lovely green colour.
And you’re done. You can now ssh to the VM and start using the database.
To connect applications, SQL Developer etc, you’ll have to add port 1521 to the subnet Security List the Database System was provisioned in. Port 1521 is already open on the VM firewall.
When Oracle (yes, I work for the big O) announced that it was building out its Autonomous Database Platform – starting with the Autonomous Data Warehouse Cloud (ADWC) – I started hearing a lot of statements that Oracle 18c would be Autonomous in and of itself. This is not the case.
So what is 18c? Its the latest version of the Oracle Database – also known as 12.2.0.2. That is its the 12.2 database with what Oracle used to call a patchset. As of 18c, Oracle has moved a “yearly” release cycle with quarterly release updates and release update revisions in between. I’ll write more on this another time.
As with releases of Oracle Database over the past 20-25 years (remember that 9i was the “Self Managing , 18c includes, adds and/or enhances a vast array of features that are designed to reduce the amount of time DBAs need to design and build the database and server infrastructure, keep the database up and running, make it perform, and keep it patched and upgraded. Features in this category include Automatic Storage Management, SQL Tuning Sets, SQL Plan Management, Automatic Memory Management, Automatic Data Optimisation and and and…
The issue with the above is that you had to choose to use almost all of them. Yes, part of the “choice” was that you had to choose to buy the license, such as Advanced Compression to get access to Automatic Data Optimisation, but putting that aside for a minute, you had to choose to use whatever feature might help you in a given situation.
Oracle Autonomous Database effectively takes the need to choose away from the user, by turning on all the automated features that Oracle have been building into Oracle Database, in favour of providing a standardised database platform that tunes, upgrades, patches and secures itself in an ongoing manner. Add into the mix an autonomous management engine to keep everything on track.
Oracle has stated that the Autonomous Database services will be available in Oracle Cloud and, over time, on the Cloud @ Customer platforms. 18c Database is the underlying database version for Autonomous.
18c will, as have past releases, be available for DBAs, devs and anyone else who is interested, to download and install on their own infrastructure. But the parts that make an Autonomous service will be cloud only offerings.
As Tim put it so succinctly,
Less time on boring shit. More time on important shit!
Hear, hear!! Stop doing the stuff you did as a junior DBA, and get stuck into the interesting stuff. Help devs write better SQL, learn features and tools you haven’t needed or didn’t have licenses to use in the past – features like Spatial & Graph, R, Database In-Memory – and apply what you discover to the problems in the context of your business and its unique needs.
BUT, this doesn’t mean that knowing how to build a database, when to choose to use a feature and when not to is not also still important. You can’t abdicate your responsibility as a consumer to ensure that you are using the right service for the right purpose at the right time. You’ll just have to do less of the grunt work over time.
In my view, Autonomous Databases are the next evolution of data management platforms and a welcome one. The less process work that needs to be done manually the better. Let’s get back to the interesting shit!
Dom covers some of the key features introduced or improved in this release.
In particular, there are some interesting improvements that I anticipate the Autonomous Database Services to use heavily under the covers. These include the Zero Impact Patching for Grid Infrastructure, Online PDB relocate – including connection redirection, improvements to patching Java in the database (OJVM) and more.
alexblyth.net 
You must be logged in to post a comment.