Just wanted to share some pieces of information from the recent DOAG annual conference that you may find interesting.
From Mike Dietrich’s presentation about Database Upgrade:
Database Replay is extremely useful to predict after-upgrade performance on a test system,
especially we can record the production load on 10g even.
From Carsten Czarski’s talk about XML DB:
With 12c, XML DB is mandatory and it provides an easy way to upload BLOBs via ftp into the database.
From Ulrike Schwinn’s talk about the Resource Manager I took away that
The resource manager becomes more and more popular and important, especially for Multitenant
- something Hans Forbrich reinforced later on.
Particularly I liked way she presented later on about ADO: Very many live demonstrations – that’s how I try to do my own presentations also :-)
Frank Schneede did a great job debunking Exadata myths. For example,
You don’t need to have all cores enabled with Exadata X4 in order to save license cost. That’s called Capacity on Demand.
If I should name one presentation that was most useful for me, it’ll be probably Frank’s.
Markus Michalewicz delivered an excellent talk as expected about RAC cache fusion:
Two important messages:
RAC scales well (far) beyond three nodes because there are never more than three nodes involved for cache fusion intercommunication.
And Multitenant and RAC are a perfect fit.
One Data Guard snippet out of Larry Carpenter’s talk about Global Data Services (GDS):
GDS makes it possible to automate the failover of the Real-Time Query service to the primary in case the physical standby has an outage.
Hans Forbrich talked about Multitenant. He showed great presentation skills and although I knew the technical details before, the way he highlighted certain aspects was still very helpful for me.
One key message was that
Multitenant is here to stay.
DBAs should learn about it and become familiar with it as soon as possible,
because sooner than later it will have to be administered in production!
When you look into V$RECOVERY_AREA_USAGE, you see a strange row at the bottom:
SQL> select * from v$recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID ----------------------- ------------------ ------------------------- --------------- ---------- CONTROL FILE 0 0 0 0 REDO LOG 0 0 0 0 ARCHIVED LOG 10.18 0 73 0 BACKUP PIECE 0 0 0 0 IMAGE COPY 0 0 0 0 FLASHBACK LOG 0 0 0 0 FOREIGN ARCHIVED LOG 0 0 0 0 AUXILIARY DATAFILE COPY 0 0 0 0
Curious what that could be? You will see values other than zero on a Logical Standby Database:
SQL> connect sys/oracle@logst as sysdba Connected. SQL> select database_role from v$database; DATABASE_ROLE ---------------- LOGICAL STANDBY SQL> select * from v$recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES CON_ID ----------------------- ------------------ ------------------------- --------------- ---------- CONTROL FILE 0 0 0 0 REDO LOG 0 0 0 0 ARCHIVED LOG 14.93 0 9 0 BACKUP PIECE 0 0 0 0 IMAGE COPY 0 0 0 0 FLASHBACK LOG 0 0 0 0 FOREIGN ARCHIVED LOG 2.03 0 26 0 AUXILIARY DATAFILE COPY 0 0 0 0
In contrast to a Physical Standby Database, this one writes not only into standby logs but also into online logs while being in standby role. That leads to two different kinds of archive logs:
When DML (like insert and update) is done on the primary 1) that leads to redo entries into online logs 2) that are simultaneously shipped to the standby and written there into standby logs 2) also. The online logs on the primary and the standby logs on the standby will be archived 3) eventually. So far that is the same for both physical and logical standby. But now a difference: Logical standby databases do SQL Apply 4) by logmining the standby or the archive logs that came from the primary. That generates similar DML on the standby which in turn leads LGWR there to write redo into online logs 5) that will eventually get archived 6) as well.
A logical standby could do recovery only with its own archive logs (if there was a backup taken before) but not with the foreign archive logs. Therefore, those foreign archive logs can and do get deleted automatically. V$ARCHIVED_LOG and V$FOREIGN_ARCHIVED_LOG can be queried to monitor the two different kinds of logs.
That was one topic of the course Oracle Database 12c: Data Guard Administration that I’m delivering as an LVC this week, by the way. Hope you find it useful :-)
As every year, there’s a long list of great speakers with interesting talks to attend at the DOAG (German Oracle User Group) annual conference. Sadly I cannot attend them all, so I’ve got to make a choice:
Datenbank-Upgrade nach Oracle 188.8.131.52 – Aufwand, Vorgehen, Kunden by Mike Dietrich, Oracle
Die unheimliche Begegnung der dritten Art: XML DB für den DBA by Carsten Czarski, Oracle
Advanced RAC Programming Features by Martin Bach, Enkitec
Automatische Daten Optimierung, Heatmap und Compression 12c live by Ulrike Schwinn, Oracle
Understanding Oracle RAC Internals The Cache Fusion Edition by Markus Michalewicz, Oracle
Die Recovery Area: Warum ihre Verwendung empfohlen ist – I have to go to that one because I present it myself :-)
Geodistributed Oracle GoldenGate and Oracle Active Data Guard: Global Data Services by Larry Carpenter, Oracle
Oracle Database In-Memory – a game changer for data warehousing? by Hermann Baer & Maria Colgan, Oracle
Oracle Distributed Transactions by Joel Goodman, Oracle
High Noon – Bessere Überlebenschancen beim Datenbank Security Shoot Out by Heinz-Wilhelm Fabry, Oracle
Tuning Tools für echte Männer und Sparfüchse – vom Leben ohne EM12c by Björn Rost, portrix Systems
Best Practices in Managing Oracle RAC Performance in Real Time by Mark Scardina, Oracle
Maximum Availability with Oracle Multitenant: Seeing Is Believing by Larry Carpenter, Oracle