*************************************************************************************************
* Description: Oracle Data Guard concepts, architecture, standby redo log, and 3 protection mode
* Date: 02:09 PM EST, 10/16/2020                         
*************************************************************************************************

		 
<1> Physical & Logical & Snaphot Standby:
     |
     |__ o. Physical Standby: block-for-block "RMAN" recovery based on the redo info, received from primary database.
     |
     |
     |__ o. Logical Standby: receving redo info from primary DB, and use a certain process converting the redo into SQL. Finally, run the converted SQL in standby DB.
     |
     |
     |__ o. Snaphot Standby: convert physical standby into snapshot standby, then do temporary testing which is closely similiar between primary and standby.
                             When testing is done, snapshot standby can be converted back to physical standby. 
                             All the received redo info will be hold off applyed on standby at the time point, when snapshot standby was converted into physical standby.
                             As soon as the snapshot got converted back into physical standby, all the redo info after that time point will be re-applyed to make standby sync.

							 
							 

<2> Data Guard services:
     |
     |__ o. Redo Transport Services
     |
     |__ o. Apply Services 
     |
     |__ o. Role Transitions




	 
<3> Standby Redo Log:
     |
     |__ o. Understand standby redo log => then, will understand Oracle Data Guard architecture => then, will understand 3 protection mode.	 
     |
     |__ o. The purpose of archive log mode: when continuous redo info being written into redo log, redo log will keep growth ultimately. 
     |      To limit redo log size, so part of the old redo info needs someplace to be saved, which is called archive log.
     |      The purpose of archive log is enlarging recover range, so reverted time point can go much further back.
     |
     |__ o. So, the most basic Data Guard architecture will be primary generates archive log, shipping and applying on standby to make both syncing. 
     |      This basic architecture is also called, ARCH transportation mode. Standby redo is not required by this mode.
     |
     |            	 
     |
     |	 
     |__ o. But, if primary server suddenly got shutdown, and the local archive logs had not been a chance shipping to standby? Then, standby will be out of sync, or data loss.
     |
     |__ o. To avoid above scenario, standby redo log comes onboard. 
     |      The main purpose of Standby Redo Log, is letting REDO info flows immediately and directly from primary Log Writter Process to standby, bypassing archived on primary side.
     |
     |__ o. Then, the enhanced process architecture will be listed as below. This advanced architecture is called, Synchronous redo transport (SYNC), and standby Redo Log is mandatory:
			

                  			
			
			


<4> Data Guard 3 protection modes:
     |
     |__ o. After understanding DG architecture, then following 3 prtection modes would be easier to understand:
     |      (Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, 
     |       and assigns a system change number (SCN) to identify the redo records for each committed transaction)
     |
     |
     |__ o. Maximum Protection: One important thing is any data changes must had been applied on primary first, and then send over this change(redo info) to standby.
     |                          So, it will never happens that one redo record appiled on standby, but not applied on primary.
     |                          The main purpose of this mode, is that primary database waits for confirmation from the standby database that redo has been received.
     |                          Then, it informs DB user that commit acknowledged on primary side, to ensure zero data loss.
     |                          By this way, primary pends on the confirmation from standby, so the performance may be dragged down. User/APP connects to primary may suffer DB hang.
     |		
     |	 
     |__ o. Maximum Performance: Never expects acknowledgment from the standby database. Primary performance will not be impacted, but has protential risky of data loss.
     |
     |
     |__ o. Maximum Availability: Normally works with SYNC redo transport. 
                                  If the primary database cannot write redo to any of its standby databases, it continues processing transactions as in ASYNC mode.

								  
             

	 
							 
	
Reference:
     |
     |__ o. https://docs.oracle.com/cd/E11882_01/server.112/e41134/concepts.htm#SBYDB4704
     |
     |__ o. https://docs.oracle.com/cd/E19509-01/820-3503/6nf1il6er/index.html	 
     |
     |__ o. https://hevodata.com/learn/standby-redo-logs-vs-online-redo-logs/
     |
     |__ o. https://oracledbwr.com/oracle-12c-step-by-step-manual-data-guard-failover/
     |
     |__ o. https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781849687904/1/ch01lvl1sec12/oracle-data-guard-architecture
	
					 

	

Your Comments