Day 2 is the first official day of the Oracle Open World (OOW) 2016. As a parallel event the Oak Table Network organized his Oak Table World (OTW) close to the Open World. I attended several sessions from OOW and OTW:

Jeremy Schneider: Ansible

Ansible is a very light software written in Python, which allows automation in deploying applications and managing systems. The main goal of the developer of Ansible Michael DeHaan was to make the process of deploying software and managing systems much simpler than it is with Puppet or Chef. Jeremy Schneider showed a demo on how easy it is to manage many systems with such an easy and still very effective tool, which uses ssh to connect to the servers and execute commands. It was impressive to see and I feel I have to check with my customer running on Redhat, if Ansible could not be an alternative to Puppet.

Frits Hoogland: Drilldown into logwriter mechanics

What happens when a user executes a “COMMIT;” ? Yes, we know that the logwriter is triggered to write the data to disk. But what happens in detail? By using the debugger dbg on Linux and setting break points in various modules, Frits could show in a very technical session what exactly happens when the foreground process runs in polling mode (i.e. instead of having the Log-Writer triggering the foreground process that the data is persistent on disk, the foreground process is polling SCN-information to detect that the data is on disk). See here.

Wei Hu, John Kanagaraj: High Availability and Sharding Deep Dive with Next-Generation Oracle Database

What is Sharding? According Oracle there is a need for World Scale applications to have a farm of independent databases. I.e. instead of 1 giant DB, the DB is partitioned into many smaller DBs (shards) running on different hosts. In contrast to RAC the data is not shared, i.e. every machine has its own disks (shared nothing hardware). So each shard stores a subset of the data. For performance reasons read-mostly data (e.g. a lookup table) is replicated between the shards. The applications have to be designed in a way that workload can be routed to a specific database in the farm. There is a choice of the sharding method: System managed (consistent hash), Composite (range-hash, list-hash) and User defined (range, list). Based on a sharding key (in the example below the CustId) the data is distributed among the shards:


CREATE SHARDED TABLE
...
PARTITION BY CONSISTENT HASH (CustId)
...;

In case a new shard is added, the data needs to be redistributed. That move of data is initiated automatically or manually (by the DBA). When it’s automated the system uses RMAN Incremental Backups and Transportable Tablespaces to redistribute the data.

Enhancements with Active Data Guard:

Improved Data Protection:

  • High speed DB compare (whole DB or individual data files) between Primary and Standby. Validates that primary and standby is physically the same, by doing a compare at the physical level.
  • RMAN validation and repair of blocks on standby that were invalidated by non-logged operations (e.g. direct path loads) on the primary.
  • Improved automatic block repair.

Active Data Guard enhancements:

  • During switchover/failover the read-only sessions remain connected and become read/write after the Active Data Guard becomes
  • Primary. That avoids a reconnect strorm after the switchover/failover.
  • In-memory DB now possible on Active Data Guard. The columns defined for In-Memory can be different on Primary and STandby.
  • Support of Diagnostic Pack (AWR), Tuning Pack and SQL Plan Analyzer on the Standby System.
  • Passwd file on standby is automatically updated.
  • Standby-first encryption: Can encrypt tablespaces on standby first, switchover and then encrypt on old primary, so that encryption can be enabled without much downtime.

 

Nigel Bayliss: Upgrading to Oracle 12c without Pain.

Nigel talked about new 12.2 Optimizer features. In 12cR1 the Optimizer adaptive features (adaptive plans and adaptive statistics with SQL Plan directives) were controlled by 1 parameter: OPTIMIZER_ADAPTIVE_FEATURES. In 12cR2 the adaptive plans and adaptive statistics have their own parameters: OPTIMIZER_ADAPTIVE_PLANS (default TRUE) and OPTIMIZER_ADAPTIVE STATISTICS (default FALSE). I.e. in 12cR2 adaptive plans are enabled by default. SQL Plan Directives will still be created, but are not used by default. So the new default settings are closer to the 11g behavior as SQL Plan Directives are not used. Franck wrote a Blog about that topic.
For migrations to 12cR2 Nigel provided specific cook books to follow to avoid plan changes initially (use SQL Plan Baselines to fix e.g. 11g plans) and then evolve to 12c.

Juan Loaiza: Oracle Database In-Memory: What’s New and What’s Coming

New features are:

  • Faster In-Memory joins: Join Groups can be defined. They specify columns, which are frequently used to join tables. The columns share the compression dictionary. The join occurrs on dictionary values rather than data: CREATE INMEMORY JOIN GROUP V_name_jg (VEHICLES(NAME), SALES(NAME)); That should bring up to 2.3 times faster join processing.
  • Precomputed expressions (e.g. Price + Price * Tax) can be cached In-Memory as user defined virtual columns. I.e. using such an expression in the query can gain from In-Memory data access.
  • In-Memory on Active Data Guard (see above).
  • In-Memory columnar format can be used on Exadata Flash Cache.
  • Data lifecycle management of In-memory data. I.e. policies can be defined to evict cold data from the In_memory Column Store.
  • The IM column data can be persisted on storage. After a restart the data can be loaded faster in memory.