Wednesday, June 30, 2021

Oracle Database Consolidation with Oracle Autonomous Database by granular (GB) storage allocation and fractional OCPU

Oracle Database Consolidation with Oracle Autonomous Database by granular (GB) storage allocation and fractional OCPU.

  

This blog post by Ranganath Srirangapatna Ramachandra and Simon Law Principal Product Managers at Oracle summarizes the capabilities/features & usefulness of Oracle Database Consolidation with Oracle Autonomous Database by granular (GB) storage allocation and fractional OCPU.

Here is a quick recap.
  • ​Oracle Autonomous Database is a self-managing database that gives users the added ability of end-to-end automation of tasks which are usually done by DBAs. 
  • This feature applies to Autonomous Database on Autonomous Database on Cloud@Customer and Dedicated Infrastructure.
  • You can now provision Autonomous databases using fractional OCPU and storage in GBs with Release Update 19.11 and higher.
  • Fractional OCPU means you can create databases < than 1 OCPU using fractional units, from 0.1 to 0.9 OCPU, with up to 10 databases running on a single OCPU.
  • Fractional OCPU and granular (GB) storage facilitates the Autonomous Database users to reduce costs through database consolidation.
  • You can now achieve greated denisty utilizing the power of the Exadata Infrastructure without sacrificing the platform's performance, availability, and security. 
  • Fractional OCPU databases will get performance-related resources allocated proportionally based on the number of OCPUs chosen with integer OCPU Autonomous databases/
  • Enter a decimal OCPU count between 0.1 and 0.9 and specify the storage size in GB on the Create Autonomous Database page To create an Autonomous Transaction Processing database with fractional OCPU and storage allocation in GB. 
  • Fractional OCPU is for < 1 OCPU. For OCPU >= 1, the increment must be in integer.
Enjoy this blog post summarizing the capabilities/features & usefulness of Oracle Database Consolidation with Oracle Autonomous Database by granular (GB) storage allocation and fractional OCPU.

Cheers.

Friday, June 4, 2021

First Database In-Memory Summit Announcement by Oracle

First Database In-Memory Summit Announcement by Oracle.

 First Database In-Memory Summit will be on June 8th and 9th: The registration is free at:  http://bit.ly/OracleDatabaseIn-MemorySummit

Keynote speakers:

Richard Niemiec - Chief Innovation Officer, Viscosity North America

Ahmed Alomari - Entrepreneur, author, and Oracle ACE

Other notable  speakers:

  • Tirthankar Lahiri, Senior Vice President, Data and In-Memory Technologies
  • Shasank Chavan, Vice President, In-Memory Technologies
  • Andy Rivenes, Database In-Memory Product Management
Enjoy this blog post annoucing the very first First Database In-Memory Summit Announcement by Oracle.

Cheers.

Tuesday, May 12, 2020

The debate about Single Purpose Database VS Converged/Consolidated Databases: Which approach/architecture is better?

The debate about Single Purpose Database VS Converged/Consolidated Databases: Which approach/architecture is better?

Here is an excellent blog post by Maria Colgan Master Product Manager at Oracle Product Management summarizing the pros and cons of each approach. Here is a quick recap on this topic.
  • Single-Purpose Databases / Purpose Built Databases
  • Single-Purpose Databases or Purpose Built Databases are architected for a singular or small number of problems/workloads: they are rather simplistic in nature with lesser functionality.
  • It is relatively easier to start development against Single-Purpose Databases because of their simplicity.
  • Single-Purpose Databases mostly scale well because they do not offer strong consistency guarantees.
  • Single-Purpose Databases end up costing significantly more in the medium to long run due to data fragmentation and higher maintenance costs.
  • Single-Purpose Best-of-Breed Databases typically creates Vendor Lock-In.
  • Single-Purpose Databases are generally used in boutique cases which, typically require higher performance requirements e.g. transaction processing systems.
  • Converged/Consolidated Databases 
  • Converged/Consolidated Databases cater to all types of data, workloads and development protocols.
  • Eliminating data fragmentation also eliminates data contagion in Converged/Consolidated Databases enabling application logic/modules to use and reuse a shared data copy across the organization.
  • Converged/Consolidated Databases enable more synergy for data and workloads making development faster.
  • Converged/Consolidated Databases make it much simpler for developers to run stuff like Cloud, Autonomous/ML, extended SQL, spatial, blockchain, IoT etc. in one singular consolidated database rather than running them across distributed Single-Purpose databases.
  • Converged/Consolidated Databases helps the overall ecosystem to be relatively lesser complex which results in lesser maintenance and development costs in the medium to long run.
  • Summary
  • The of Single-Purpose Databases or Purpose Built Databases should be well thought out for a very limited/focused set of problems/tasks as, they come at extra maintenance/cost in the medium to long run.

This video by Juan Loaiza & Andrew Sutherland gives a good summary on this debate.


I hope you got a quick overview of the pros and cons of this ongoing debate: Single Purpose Database VS Converged/Consolidated Databases: Which approach/architecture is better?

Cheers.

Monday, May 11, 2020

Oracle Database 19c is now certified on Linux 8

Oracle Database 19c is now certified on Linux 8 - there is a very good blog post by Mike Dietrich Master Product Manager for Oracle Database Upgrade and Migrations.

Here is a quick recap on this topic.
  • Minimum Release Update is 19.7 (Or 19.6 with patches or higher.
  • Goto My Oracle Support > Certifications tab and then enter  “Oracle Database“, “19.0.0.0.0” and either “Linux x86-64 Oracle Linux 8.x” or “Linux x86-64 Red Hat Enterprise Linux 8“.
  • Reference Document: MOS Note: 1369107.1
  • Minimum Kernel Versions: 
    • Oracle Linux 8.1 with the Unbreakable Enterprise Kernel 6: 5.4.17-2011.0.7.el8uek.x86_64 or later
    • Oracle Linux 8.0 with the Red Hat Compatible kernel: 4.18.0-80.el8.x86_64 or later
Oracle Database 19c is certified on OL8 and RHEL8

Oracle Database 19c is certified on OL8 and RHEL8


Enjoy Oracle 19c on Linux 8.
Cheers.

Sunday, May 10, 2020

Oracle Standard Edition High Availability Released - A Quick Summary of New Features

Oracle released a High Availability version of Oracle Standard Edition (SE2) recently.

There is a very good blog post by Markus Michalewicz Senior Director Oracle Product Management summarizing the following new features. Here is a quick recap of what's new with SE2.
  • With SE2 Cluster-based failover using Oracle Clusterware is now available for single-instance Standard Edition Oracle Databases. 
  • With this latest release of Oracle Standard Edition, you can now use standard Oracle Clustering features such as Automatic Storage Management (ASM), ASM Cluster File System (ACFS) & Oracle Clusterware on Oracle Standard Edition.
  • Oracle Standard Edition is completed integrated with 19c RU 19.7.
  • However, Oracle Standard Edition High Availability DBs are NOT RAC enabled - to RAC enable your Oracle databases, you still do need Real Application Clusters (RAC) option enabled.
  • There is no direct upgrade path for a single instance or a pre-19c RAC Standard Edition 2 Database
  • The Standard Edition High Availability option can be failed over to an unlicensed machine for up to 10 days.
  • SE2 is available on Windows, Linux & Solaris family of Operating Systems.
Enjoy the SE2 version of Oracle.

Cheers.

Thursday, April 30, 2020

Faster Oracle Database Upgrades but with lesser memory

Here is a shout out to very good blog post by Mike Dietrich Master Product Manager for Oracle Database Upgrade and Migrations: Faster Oracle Database Upgrades but with lesser memory.

Quick Recap on this topic.

  • Reducing SGA and PGA sizes for Database Upgrades makes the whole process faster by leveraging lesser memory.
  • Leverage Large Pages for Database Operations and Upgrades.
  • Database is started in Upgrade Mode during restarts.
  • Upgrades don't touch User Data.

Cheers.