Autonomous Database - Dedicated : Getting Started with Operational Maintenance Policies

As many of you realize, Oracle Autonomous Database has two deployment choices; Serverless and Dedicated.

Autonomous Serverless is meant to get database users up and running quickly with zero interaction in anything related to administration. Serverless is in a sense traditional cloud, a multi-tenant database service using shared resources. In many respects, Serverless is the pinnacle of what Oracle means to “go Autonomous” with database in cloud, you simply get a secure connection and start using the database for your applications or data warehouses, there is minimal to zero interaction with the administrative side of running the database service. 

On the other hand, Autonomous Dedicated deployments are a step beyond traditional cloud, designed to provide the ultimate in resource isolation, performance and allows database users a way thru policy controls to influence how Oracle’s Autonomous operations function.

With Autonomous Dedicated, at a macro level Fleet Administrators can budget dedicated resources to different work groups (LOBs, Project Teams) within a single tenant. Fleet Administrators then turn over access to the budgeted resources to the work group for a granular level of self-service, an experience that has a parallel to the experience of Oracle’s Autonomous Serverless. However, it’s not multi-tenanted, all IaaS resources are dedicated to the single tenant, yet in the same self-service format. Autonomous Dedicated brings the ultimate corporate level governance and regulatory capabilities while removing the red tap commonly known to reduce business agility.  

Autonomous Dedicated policy controls make it possible to influence the level of resource isolation, database software versioning and lifecycle, over provisioning and peak usage of a database’s underlying resources. Let’s talk about database software versioning and lifecycle and get into an example of how to influence the Autonomous operations. In the next blog, we will then show an example of integrating notifications about autonomous operations into a Slack channel or other preferred methods of receiving service notifications.

With Serverless, Oracle sets all policies on software versioning and lifecycle. The exact software version, how and when it gets updated is completely opaque to the service consumers. With Dedicated, policy controls on software versioning and lifecycle make it possible for database service users to set policies so that mission critical applications can treat development and test separately from pre-production and production databases. For example, policies can influence Oracle Autonomous Database operations to update development and test with the very latest software versions, while pre-production uses a revision level update that applies 30 days before that same revision applies to production. Complex applications then have an ability to run regressions in pre-production and only apply validated revisions to the actual production. This only begins to touch on the way database users can influence how Autonomous operations run. 

Lets take a quick walk thru of how to setup these software versioning lifecycles. This is easily done by setting up lifecycle defaults. Using the API, CLI, SDK or Console it’s easy to configure the defaults. Below is a series of screen shots from the console.

Head on over to one of the Autonomous Database workloads:

Once at the Autonomous Database resource page, you will notice 3 different Autonomous Database resources.  Autonomous Exadata Infrastructure (AEI), Autonomous Container Database (ACD), Autonomous Database (ADB).  The AEI and ACD are Autonomous Dedicated specific service resources and are where to setup the software version lifecycle. The ADB service resource is common for both Serverless and Dedicated.

Fleet Administrator sets up the default software version maintenance schedule at the AEI level during provisioning, although the defaults can be modified at any time for an existing AEI. Click on the Create Autonomous Exadata Infrastructure button.

At the bottom of the AEI provisioning screen, you will see a Configure the Automatic Maintenance section, where you should click on the Modify Schedule button. If you do not customize the schedule, then it behaves like Serverless and Oracle will set a schedule.

Clicking that Modify Schedule button brings up a calendaring system to set maintenance window preferences. If desired, you can narrow the window down to a specific start time. The schedule is inherited from the AEI to the ACD and in a future release there will be a separation of schedule for the AEI and ACD.

Similarly, a Fleet Administrator or a Database Admin sets up the software version policy at the ACD level during provisioning, although the defaults can be modified at any time for an existing ACD. Click on the Create Autonomous Container Database button.

At the bottom of the ACD provisioning screen, you will again see a Configure the Automatic Maintenance section, where you should click on the Modify Maintenance Type button. If you do not customize the Maintenance Type, Oracle will default to Release Update to keep you on the latest available software version. In a future release, you will be able to select an exact software version and Oracle will honor the implied strategy of applying the next Update or Revision based on your previous selection. Critical updates related to security or other service related issues will also appear in the same way, a unique version that can be selected, which will initially become available as a new custom scheduled update.  

Modify Maintenance Type to your preference of Release Update or Update Revision, then click the Update Automatic Maintenance button to save your policy.

Even though you've set all these defaults during provisioning, using the ACD resource list (which you can get to using the bread crumbs at the top of the Details page), you can Navigate to any given ACD details (below you would click on PrePRod or FLEET_ACD links), including maintenance where you can change your defaults and change timing and other aspects of scheduled maintenance.

On the details page, you can find links to view your current settings, see maintenance that is currently scheduled to occur and view a history of maintenance actions.

You will see details like the following, where you have controls to take various actions to change defaults, software versions, schedules, defer etc. 

OK, it's that simple, now you know how to setup a software version lifecycle for a specific AEI / ACD and you can understand how different AEI / ACD can be given unique policies on how a development and test environment should be treated as opposed to pre-production and production instances. For example, schedules for production can be setup to mirror the pre-production schedule and version, but with a 1 month delay in the operation. If an issue arises in your application as a combination of your application changes and a particular software version update, it would be detected in your pre-production, you can then defer the production operation until the issue is resolved. 

This flexibility in managing separation of software version, scheduling allows new adopters of Autonomous Database Services to mitigate any perceived risk in moving the most mission critical application databases to Oracle Cloud.

Source: oracle.com

Continue reading

Oracle’s latest MySQL HeatWave cloud database simplifies use of machine learning

Machine learning is delivering real profits to more companies by automating decision-making and enhancing digital products. Yet the flood of data pouring into these statistical prediction systems has created another problem: How to get reams of data ready for powerful computers to analyze amid of a dearth of machine learning expertise.

Twenty-seven percent of companies surveyed by McKinsey & Company last year reported that at least 5% of their operating profit was attributable to artificial intelligence (AI) usage, up from 22% of companies in 2020. In the survey of 1,843 global companies, 56% said they’re using AI in at least one area, chiefly to automate customer service, improve products, segment customers, and model risk.

Yet organizations have their data hived away in myriad databases with different departments using different approaches. Ferrying information to machine learning systems and putting it in a form that’s ready to analyze adds cost and time drag. “AI needs data, and for enterprises, moving data around is cumbersome, slow, and expensive,” says Holger Mueller, vice president and principal analyst at tech advisory firm Constellation Research.

The latest version of Oracle MySQL offers a better approach: Build machine learning models into the database, so you can leave the data where it is. “Bringing the machine learning to the data is a smart architecture and design choice,” Mueller says.

First released two years ago, MySQL HeatWave runs as a service on Oracle Cloud Infrastructure and lets users of the widely adopted MySQL Database combine transaction processing and data analysis in a single database. It runs database queries in computer memory to increase their speed.

Machine learning built in

The latest iteration of the software puts machine learning capabilities inside the MySQL HeatWave Database and can automate the process of creating and training ML models, then unleashing them on live data. MySQL HeatWave can train models on available data and tune them to improve accuracy based on how well they predict outcomes. That means when organizations’ data is inside MySQL Database, as much of it already is, they can skip the work of extracting it, changing its format, and loading it into another ML system—a process that can take hours. Developers and data analysts can also build ML models using the familiar database SQL language without having to learn new tools or languages.

“HeatWave is easy to use, period,” says Matt Kimball, an analyst at Moor Insights & Strategy. “The biggest barrier to adoption in the world of ML is complexity—organizations can’t find the right talent and the best hardware. With HeatWave, they can realize the promise of machine learning more quickly.”

Sales of cloud data warehouses are expected to grow sharply this year as businesses use them for tasks, such as managing supply chains, hunting for sales opportunities, or analyzing medical data. The systems tap databases, the web, business applications, and sensors to gather data in one place, analyze it, and give companies a clearer view of operations, sales, and customer behavior.

Oracle published machine learning benchmarks performed across a large number of publicly available machine learning datasets using different cloud providers—research noted by several analysts as an industry first. On average, on the smallest cluster, MySQL HeatWave ML-trained machine learning models were 25 times faster at 1% of the cost of Amazon Web Services’ (AWS) Redshift ML. The benchmarks based on public ML datasets show MySQL HeatWave delivering better price performance than Google’s BigQuery, Microsoft Azure Synapse, and Snowflake, as well as AWS’s Redshift with its query accelerator.

Less time spent using a cloud service can mean lower computing bills, and the new MySQL HeatWave version also lets customers scale up without downtime.

Last year, Oracle introduced software called My SQL Autopilot for using AI to optimize and automate the MySQL HeatWave service. “Autopilot used machine learning to operate the database. Now it’s about using ML on the data,” says Mueller.

MySQL HeatWave can also take models tuned in MySQL and use them to answer queries from popular machine learning notebook services for code and data, such as Jupyter and Apache Zeppelin.

Oracle plans to release MySQL HeatWave to run on other cloud providers’ infrastructure, including AWS, Oracle Executive Chairman and Chief Technology Officer Larry Ellison said during a conference call with financial analysts last month.

Edward Screven, Oracle’s chief corporate architect, said during an online presentation that companies are finding it hard to achieve their machine learning ambitions. “If you use conventional tools, if you use what comes out of the box from most vendors, from most clouds, machine learning is hard, and it's expensive,” he said. In contrast, “you don’t need to be an expert to use machine learning with your data stored in MySQL HeatWave.”

The new capabilities are available at no extra charge for MySQL HeatWave customers in all of Oracle’s global cloud regions. Oracle is also making both the ML and TPC-DS benchmark tests public for customers to perform themselves. “That really lends credibility to the price and price-performance claims,” says Moore Insights’ Kimball.

Source: oracle.com

Continue reading

Oracle Database 21c Upgrade: good to know

The latest release of the Oracle database 21.3 can be downloaded from here. 21c is available for Linux, HP-UX and Windows. By using Oracle Fleet Patching & Provisioning, you can perform a direct upgrade to Oracle database release 21c from the following releases:

Any 19c

Any 18c

12.1.0.2 or 12.2.0.1

11.2.0.3 or 11.2.0.4

Oracle Fleet Patching and Provisioning is a software lifecycle management method for provisioning and maintaining Oracle homes. Configuring Oracle Fleet Patching and Provisioning (Oracle FPP) involves creating an Oracle Fleet Patching and Provisioning Server, adding gold images to the server, and creating working copies of gold images to provision software.

The Oracle Grid Infrastructure on which the database to be upgrade is running must be at least of the same release or later than the database release to which you will be upgrading.

The source Oracle home to be upgraded can be either a managed working copy, i.e., an Oracle home provisioned using Fleet Patching and Provisioning, or an unmanaged home, i.e., an Oracle home not provisioned using Fleet Patching and Provisioning. If you are upgrading an unmanaged Oracle home, you have to provide the complete path of the database for upgrade.

Otherwise, without Oracle FPP, you can upgrade directly from 12.2.0.1, any 18c or any 19c.

Here is what you need to know about compatibility:

◉ Before upgrading to Oracle Database 21c, you must set the COMPATIBLE initialization parameter to at least 12.2.0 (I am unsure if 11.2.0 is ok as well)

◉ In Oracle Database 21c, when the COMPATIBLE initialization parameter is not set in your parameter file, the COMPATIBLE parameter value defaults to 21.0.0

◉ Installing earlier releases of Oracle Database on the same computer that is running Oracle Database 21c can cause issues with client connections

Starting with Oracle Database 21c, non-CDB Oracle Database upgrades to non-CDB architecture are de-supported:

Option 1: Convert the non-CDB to a PDB before upgrade: with this option, you plug in the non-CDB Oracle Database release to the same release CDB. (For example, plug in a non-CDB Oracle Database Release 19c into an Oracle Database 19c release CDB). Finish converting the non-CDB Oracle Database to a PDB. Then, upgrade the entire CDB, with its PDBs, to Oracle Database 21c

Option 2: Plug in the non-CDB, upgrade, and finish converting the non-CDB to a PDB after upgrade: with this option, you plug in a non-CDB Oracle Database release to an OracleDatabase 21c CDB. Upgrade the plugged-in non-CDB Oracle Database to Oracle Database 21c. Then, finish converting the non-CDB Oracle Database to a PDB.

Here is what you need to know about the DBUA and the Oracle home:

◉ Starting with Oracle Database 21c, Database Upgrade Assistant (DBUA) is replaced by the AutoUpgrade utility

◉ Starting with Oracle Database 21c, the default network administration directory changes from the previous default in the local Oracle home, Oracle_home/network (for example, /u01/app/oracle/product/19.1.0/dbhome_1/network), to a new location

◉ The new default location is the shared Oracle Base Home, in the path ORACLE_BASE/ homes/HOME_NAME/network/admin

◉ Starting with Oracle Database 21c, an Oracle Database installation configures all Oracle Database homes in read-only mode by default

Note last what is being changed about security and parameters:

◉ Starting with Oracle Database 21c, the data types DBMS_CRYPTO_TOOLKIT_TYPES and package DBMS_CRYPTO_TOOLKIT are desupported

◉ The init.ora parameters UNIFIED_AUDIT_SGA_QUEUE_SIZE, UNIFIED_AUDIT_SGA_QUEUE_SIZE, AUDIT_FILE_DEST, AUDIT_SYS_OPERATIONS, AUDIT_SYSLOG_LEVEL and AUDIT_TRAIL have been desupported

◉ Desupport of IGNORECASE parameter for passwords

Starting in Oracle Database 21c, the IGNORECASE parameter for the orapwd file is desupported and all newly created password files are case-sensitive

◉ Desupport of DISABLE_DIRECTORY_LINK_CHECK

The DISABLE_DIRECTORY_LINK_CHECK parameter is desupported, with no replacement

Source: juliandontcheff.wordpress.com

Continue reading

Move Your Database into the Cloud with the Spring 2022 Update of OCI Database Migration

We are pleased to announce a new release of Oracle Cloud Infrastructure Database Migration (DMS) to improve your user experience.

Oracle Cloud Infrastructure Database Migration is a fully-managed service that provides a high performing, self-service experience for migrating databases to Oracle Cloud Infrastructure (OCI). It provides logical online and offline migration for enterprise-level database migration with minimal downtime. Oracle Cloud Infrastructure Database Migration is based on industry-leading Oracle Zero Downtime Migration engine utilizing Oracle GoldenGate replication.

The new features include:

◉ Amazon RDS as a source - You can now migrate Amazon RDS for Oracle databases to OCI autonomous and co-managed databases using offline migration.

◉ Interactive Cloud Premigration Advisor (CPAT) results - Browse and filter results of CPAT directly in the OCI Console and exclude offending objects or use remedial scripts. CPAT performs analysis of the source database, looking for database features that are not supported or problematic when migrating to Oracle's Autonomous Cloud offerings.

◉ Auto-create tablespaces - Choose between auto-creating or remapping tablespaces on target database.

◉ Dynamic display of excluded objects - Provide report of source database objects excluded from migration and why they were excluded.  

Please see a full migration in this new Demo Video!

For more details and links to updated documentation, see What’s New for Oracle Cloud Infrastructure Database Migration.

Source: oracle.com

Continue reading

In-Place Upgrade for Database Cloud Service (DBCS) VM DB Systems

We are pleased to announce the general availability (GA) of upgrading the Operating System (OS) and Grid Infrastructure (GI) stack on Database Cloud Service (DBCS) VM DB Systems.

This feature provides an in-place upgrade option for DB Systems running Oracle Linux 6 (OL6) and Grid Infrastructure 12.2 or 18c to Oracle Linux 7 (OL7) with Grid Infrastructure 19c while keeping the database version the same. Additionally, customers can also upgrade their database to 19c and optionally convert it to CDB/PDB architecture.

Read More: 1Z0-068: Oracle Database 12c - RAC and Grid Infrastructure Administration

With the in-place upgrade capability of OS and GI for VM DB Systems, you can now

◉ Perform an in-place upgrade which keeps the characteristics of your VM DB System – such as SCAN Name, SCAN IPs, private IP addresses, and hostnames intact - during the upgrade process

◉ Upgrade Oracle Linux version from OL6 to OL7

◉ Upgrade the Grid Infrastructure to the latest or the previous GI 19c version (N-1)

◉ Upgrade with minimal downtime in approximately 2 hours using cloning technology

◉ Fallback to a snapshot if a roll back is required

OCI Console Experience

The Console has been redesigned to use a single execution page for updates and upgrades. From the Bare Metal, VM, and Exadata service home page, navigate to DB Systems and click on the 'View' button in the newly displayed version information section:

On the Updates screen, you will find GI and database updates and upgrades. If your VM OS version is OL6, database upgrades to 19c are not possible until the OS is upgraded to OL7.

So, let's first upgrade the DB System to OL7 and 19c by choosing "Run Precheck" to ensure there are no common errors detected and then APPLY to upgrade the VM DB System to OL7 and 19c. The OS version relates to the GI version, but this will be separated in a future release.

A confirmation dialog is displayed which requires you to type in the DB System name. For this upgrade, all nodes will be shut down, including both RAC nodes.

Once "Upgrade DB System" is pressed, the upgrade process will start. A "Rollback" option becomes available in the "Update History" screen if upgrade is not successful.

Considerations

◉ Only supports upgrade to GI Version 19c.

◉ The upgrade process will incur downtime on your DB Systems, so this should be planned accordingly.

◉ It is advisable to have a complete standalone backup of the database before trying the upgrade.

◉ As of today, while private IP addresses and hostnames are kept, the ephemeral Public IP addresses will change.

◉ Avoid launching new VM DB Systems within the same subnet during the upgrade process. There is a short time interval when private IP addresses and hostnames are freed, and it will block the upgrade process if another VM DB Systems uses the same IP or hostname.

◉ OS customizations will need to be reapplied as the upgrade exchanges the boot volume.

◉ Any GI clusterware customizations, such as services, additional VIPS, will need to be reapplied since the Grid Infrastructure is reinstalled.

◉ It is recommended to disable the automatic backups before executing the upgrade so archive log backups are not kicked off during the upgrade time. The upgrade process will disable and re-enable the automatic backups.

◉ For databases with a Data Guard association, the upgrade must first be performed on the Standby database. This ensures no re-instantiation is required in case of a rollback as the standby will continue be a higher release than that of the primary.

◉ For Data Guard association, it is advised for the protection mode to be switched to "Maximum Performance" before the upgrade to avoid primary database running into NET_TIMEOUT. Once the upgrade is completed, the protetion mode can be turned back to "Maximum Availability".

Availability

OS and GI upgrade of VM DB Systems is available in all OCI commercial regions via OCI console, API, and SDK.

Source: oracle.com

Continue reading

OCI Vault Integration with Oracle Database Cloud Service

Oracle Database Cloud Service (DBCS) uses Oracle Transparent Data Encryption (TDE) to protect data at rest for its databases. TDE is a two-tier key architecture comprising data encryption and master encryption keys. The data encryption keys that protect the tablespaces are stored within the database but are wrapped by a single master encryption key. In the case of Oracle-managed keys, the master keys are stored in an Oracle Wallet - a PKCS#12 standard-based key store file - on the filesystem of the DBCS system outside of the database.

We are pleased to announce the general availability of Database Cloud Service (DBCS) integration with the OCI Vault service. Users now have the control to create and manage TDE master keys within the OCI Vault that protect their DBCS VM databases. With this feature, users have the option to continue keeping the TDE master encryption keys in Oracle-managed file-based encryption on the DB System or use the OCI vault service to store and manage the master encryption keys. The OCI Vault keys used for protecting databases are stored in a highly available, durable, and managed service.

With OCI Vault integration with DBCS, customers can now

◉ Centrally control and manage TDE master keys by enabling OCI Vault based key encryption while provisioning Oracle databases on DBCS.

◉ Have their TDE master keys stored in a highly available, durable, and managed service wherein the keys are protected by hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification.

◉ Rotate their encryption keys periodically to maintain security compliance and, in cases of personnel changes, to disable access to a database.

◉ Migrate from Oracle-managed keys to customer-managed keys for their existing databases.

◉ Bring in their own keys, that's BYOK (Bring Your Own Key), and use them while creating databases with customer-managed encryption.

Databases using customer-managed encryption support VM DB System cloning, in-place restore, out-of-place restore, intra-region Data Guard configuration, and PDB specific operations like PDB creation and local cloning.

OCI Console Experience

Let's take a look at the OCI Vault integration for DBCS using the OCI console:

◉ Enable customer-managed encryption during database provisioning

◉ View the encryption method being used for the database

◉ Rotate customer-managed key

◉ Migrate from Oracle-managed key to customer-managed key

In order to use customer-managed keys with the DBCS VM database, you should first access the OCI Vault service, and create a Vault, and an encryption key. The key protection method can either be HSM (Hardware Security Module) or Software. The encryption key algorithm you use must be AES-256.

Next, you should ensure the required IAM policy is set for the DB System to access the Vault and managed keys. Once these prerequisite steps are complete, you can create a DBCS VM database protected by customer-managed keys.

Enable ustomer-managed encryption during database provisioning

From the Bare Metal, VM, and Exadata service home page, navigate to DB Systems and click on 'Create DB System'.   Fill in the DB System-specific details, and go to the 'Database Information section. At the bottom of the page, click on 'Show Advanced Options' and go to the 'Encryption' tab. Choose 'Use customer-managed keys' which enables your data to be encrypted with a Vault service encryption key. Choose a Vault and a Key from the dropdown. Optionally you can choose a key version especially if you want to bring your on-premise keys to the cloud. If you don't choose that, the latest version of the key is used for encryption.

View the encryption method being used for the database

On the database details page, you can see if the key for protecting your database is managed in a file-based wallet (Oracle-managed encryption) or in the OCI Vault service (customer-managed encryption). If it is managed by OCI Vault service, you will see the encryption key name and its OCID on the page.

Rotate customer-managed key

On the database details page, navigate to More Actions → Rotate Key. The rotate key action will generate a new key version.

Migrate from Oracle-managed key to customer-managed key

Go to the Database details page, and navigate to More actions → Manage Encryption Key. Choose 'Use customer-managed keys', and select 'Vault' and 'Master encryption key' from the dropdown. You need to provide TDE wallet password of the database, and additionally, the Sys administrator password if the database whose key is being migrated is a Data Guard Primary.

Considerations

◉ OCI vault integration for DBCS is only available for VM DBCS for Oracle database versions 19.13 and later.

◉ Databases using customer-managed encryption cannot be restored On-Premises.

◉ Vault key management for DBCS supports the unified mode of TDE management - all key versions will be from the same OCI Vault key.

◉ Key migration from Oracle-managed to customer-managed requires that CDB and its PDBs are opened, and all the tablespaces are opened read-write.

Source: oracle.com

Continue reading