With a Data Guard Configuration in Maximum Performance protection mode, don’t go to Maximum Protection directly, because that leads to a restart of the primary database:
DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxPerformance Databases: prima - Primary database physt - Physical standby database physt2 - Physical standby database (receiving current redo) Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> edit configuration set protection mode as maxprotection; Operation requires shutdown of instance "prima" on database "prima" Shutting down instance "prima"... Database closed. Database dismounted. ORACLE instance shut down. Operation requires startup of instance "prima" on database "prima" Starting instance "prima"... ORACLE instance started. Database mounted. Database opened.
Instead, go to Maximum Availability first and then to Maximum Protection:
DGMGRL> edit configuration set protection mode as maxperformance; Succeeded. DGMGRL> edit configuration set protection mode as maxavailability; Succeeded. DGMGRL> edit configuration set protection mode as maxprotection; Succeeded.
The demo was done with 12c, involving a cascading standby database, but the behavior is the same in 11g already. The odd thing about it is that DGMGRL will restart the primary without warning. Wanted to share that with the Oracle community for years but always got over it somehow.
The Flash Cache Mode still defaults to Write-Through on Exadata X-4 because most customers are better suited that way – not because Write-Back is buggy or unreliable. Chances are that Write-Back is not required, so we just save Flash capacity that way. So when you see this
CellCLI> list cell attributes flashcachemode WriteThrough
it is likely to your best :-)
Let me explain: Write-Through means that writing I/O coming from the database layer will first go to the spinning drives where it is mirrored according to the redundancy of the diskgroup where the file is placed that is written to. Afterwards, the cells may populate the Flash Cache if they think it will benefit subsequent reads, but there is no mirroring required. In case of hardware failure, the mirroring is already sufficiently done on the spinning drives, as the pictures shows:
That changes with the Flash Cache Mode being Write-Back: Now writes go primarily to the Flashcards and popular objects may even never get aged out onto the spinning drives. At least that age out may happen significantly later, so the writes on flash must be mirrored now. The redundancy of the diskgroup where the object in question was placed on determines again the number of mirrored writes. The two pictures assume normal redundancy. In other words: Write-Back reduces the usable capacity of the Flashcache at least by half.
Only databases with performance issues on behalf of writing I/O will benefit from Write-Back, the most likely symptom of which would be high numbers of the Free Buffer Waits wait-event. And Flash Logging is done with both Write-Through and Write-Back. So there is a good reason behind turning on the Write-Back Flash Cache Mode only on demand. I have explained this just very similar during my present Oracle University Exadata class in Frankfurt, by the way :-)
What happens when you unplug a pluggable database that has local users who have been granted common roles? They get copied upon plug-in of the PDB to the target container database!
SQL> connect / as sysdba Connected. SQL> create role c##role container=all; Role created. SQL> grant select any table to c##role container=all; Grant succeeded. SQL> connect sys/oracle_4U@pdb1 as sysdba Connected. SQL> grant c##role to app; Grant succeeded. SQL> grant create session to app; Grant succeeded.
The local user app has now been granted the common role c##role. Let’s assume that the application depends on the privileges inside the common role. Now the pdb1 is unplugged and plugged in to cdb2:
SQL> shutdown immediate Pluggable Database closed. SQL> connect / as sysdba Connected. SQL> alter pluggable database pdb1 unplug into '/home/oracle/pdb1.xml'; Pluggable database altered. SQL> drop pluggable database pdb1; Pluggable database dropped. SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 220.127.116.11.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options [oracle@EDE5R2P0 ~]$ . oraenv ORACLE_SID = [cdb1] ? cdb2 The Oracle base for ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1 is /u01/app/oracle [oracle@EDE5R2P0 ~]$ sqlplus / as sysdba SQL*Plus: Release 18.104.22.168.0 Production on Tue Jul 29 12:52:19 2014 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 22.214.171.124.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> create pluggable database pdb1 using '/home/oracle/pdb1.xml' nocopy; Pluggable database created. SQL> alter pluggable database pdb1 open; Pluggable database altered. SQL> connect app/app@pdb1 Connected. SQL> select * from scott.dept; DEPTNO DNAME LOC ---------- -------------- ------------- 10 ACCOUNTING NEW YORK 20 RESEARCH DALLAS 30 SALES CHICAGO 40 OPERATIONS BOSTON SQL> select * from session_privs; PRIVILEGE ---------------------------------------- CREATE SESSION SELECT ANY TABLE SQL> connect / as sysdba Connected. SQL> select role,common from cdb_roles where role='C##ROLE'; ROLE -------------------------------------------------------------------------------- COM --- C##ROLE YES
As seen above, the common role has been copied upon the plug-in like the picture illustrates:
Not surprisingly the local user app together with the local privilege CREATE SESSION was moved to the target container database. But it is not so obvious that the common role is copied then to the target CDB. This is something I found out during delivery of a recent Oracle University LVC about 12c New Features, thanks to a question of one attendee. My guess was it will lead to an error upon unplug, but this test-case proves it doesn’t. I thought that behavior may be of interest to the Oracle Community. As always: Don’t believe it, test it! :-)