Your search did not match any results.
This demonstrates how Data Guard provides unique protection from data corruption caused by lost writes. A data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, while in fact the write did not occur in the persistent storage. When a primary database lost write corruption is detected by a Data Guard physical standby database, Redo Apply (MRP) will stop and the standby will signal an ORA-752 error to explicitly indicate a primary lost write has occurred (preventing corruption from spreading to the standby database). For more information on lost write protection and additional ways that Oracle Data Guard can prevent, detect, or automatically repair data corruption see My Oracle Support Note 1302539.1
This demonstrates capabilities in Oracle Database 126.96.36.199 for easily creating a Data Guard Broker configuration, using the Broker to validate that Data Guard is functioning correctly, and performing basic management tasks using the Data Guard Broker command line interface DGMGRL. Management tasks demonstrated include switchover and automatic restart of database services on the new primary database, failover and automatic restart of database services and publication of FAN events (Fast Application Notification) to inform OCI and JDBC clients that a failover has occurred, and easy reinstatement of the original primary as a synchronized standby of the new primary database. After downloading and starting the demonstration, click on the menu bar at the bottom of the page to manually advance through each of the operations.
This demonstrates automatic failover between an Oracle RAC primary database and an Oracle RAC standby database in an MAA configuration. Following failover, the original primary is automatically reinstated as a standby database, and automatically resynchronized with the new primary database. High availability and maximum data protection are achieved during a site failure with zero manual intervention required. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo. Click here for the accompanying presentation that includes the production experiences of Amazon.com with Data Guard Fast-Start Failover .
This demonstration shows how to convert a physical standby to a transient logical standby database and implement a rolling database upgrade with minimal downtime. The standby database will revert to its original state as a physical standby database when the upgrade is complete - through use of the KEEP IDENTITY clause. This benefits physical standby users who wish to execute a rolling database upgrade without investing in redundant storage and effort that would otherwise be needed to create a logical standby database. This process utilizes SQL Apply in a very limited way - as the method to resynchronize the standby database following its upgrade to the new release and to maintain synchronization until it first assumes the primary production role. The original primary database (now a standby) is then mounted in a new Oracle home and upgraded to the new release via the redo stream using Redo Apply (the physical standby apply process).
Starting with Oracle Database 11g release 1, the Oracle MAA implemented best practices for performing rolling database upgrades (e.g. upgrade to new patch set or new Oracle Database release) using Active Data Guard in a rolling manner with a transient logical Standby. In Oracle Database 12c Release 1, the 'Rolling Upgrade Using Oracle Active Data Guard' feature provides a streamlined method of performing rolling upgrades reducing some 42 steps down to 6 using the DBMS_ROLLING PL/SQL package. This demonstration shows just how simple and controlled the rolling upgrade process is now with this new method.
The impact that synchronous zero data loss protection has on database performance can lead to undesirable compromises. Customers with large distance between sites must compromise on protection and use asynchronous transport, accepting data loss in return for acceptable performance. Active Data Guard Far Sync, a new capability for Oracle Database 12c, eliminates compromise by extending zero data loss protection to any standby database located at any distance from a primary database, and doing so at minimal expense and without additional complexity. This demonstration shows how Active Data Guard 12c Far Sync is configured and zero data loss failovers performed.
As of Oracle Database 12c Release 1 (12.1), the new temporary undo feature allows the undo for changes to a global temporary table (GTT) to be stored in the temporary tablespace as opposed to the undo tablespace. Undo stored in the temporary tablespace does not generate redo, thus enabling redo-less changes to global temporary tables. This allows DML operations on global temporary tables on Oracle Active Data Guard standbys. In addition sequences created at the primary database can be accessed from Active Data Guard standby databases as well, both global to the entire Data Guard configuration or local only to the current session. This demonstration shows how to enable and use GTTs and both Global and Session Sequences on an Active Data Guard standby database.
This demonstrates how Active Data Guard 11g will automatically repair physical on-disk block corruption at a primary database. Block-level data loss usually results from intermittent, random I/O errors, as well as memory corruptions that are written to disk. Normally when Oracle discovers a corruption it marks the block as media corrupt, writes it to disk, and returns an ORA-1578 error to the application. No subsequent read of the block will be successful until the block is recovered manually. However, if the corruption occurs on a primary database that has an Active Data Guard standby, block media recovery is performed automatically, transparent to the application, using a good copy of the block from the active standby database. Conversely, bad blocks on an active standby database are automatically recovered using the good version from the primary database.
This demonstrates how Active Data Guard 11g will automatically repair physical on-disk block corruption that occurs at a standby database completely independent of the primary. Detection and automatic repair of physical on-disk block corruption at a standby database is initiated by 1) any read-write transaction at the primary database, 2) any read-only transaction at the primary database, or 3) any block that is read by media recovery or by read-only transactions at the Active Data Guard standby. Automatic repair is transparent to both Redo Apply and to applications running at either the primary or active standby database; Oracle will signal that the repair has occurred in the database alert log. Active Data Guard uses multiple approaches to detect and automatically repair corruption at a standby database both to maintain data protection and to provide high availability for read-only workload offloaded to the standby system.
This demonstrates the benefits of using a synchronized physical standby database that is open read-only to offload ad-hoc queries and reporting from your production database, thus achieving scalable performance and fast, predictable response times for read-write business transactions. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo. Click here for Active Data Guard MAA Best Practices.
This demonstrates how to utilize an Active Data Guard standby database as a source for Data Pump to extract data for other uses. The demonstration also shows how to use Standby Statspack to collect statistics from an Active Standby Database to assist in query tuning. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo. See My Oracle Support Note 454848.1 for details on using Standby Statspack.
This demonstrates how to configure automatic monitoring of an Active Data Guard standby database. Should the standby apply lag exceed designated service level agreements for any reason (e.g. a network outage or if apply stops to protect against primary data corruptions), Data Guard will automatically notify applications that the standby is not current and read-only queries can be redirected to another active standby database or the primary to insure service level objectives are met. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo.
There are many read-mostly applications that are able to use an Active Data Guard standby database to offload read-only workload from the primary database by redirecting a small number of required DML operations back to the primary database. This demonstration shows how to configure DML redirection using Active Data Guard. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo.
This demonstrates integrated automatic failover of a PeopleSoft Application while the underlying database also undergoes a failover, through an automatic Data Guard Fast-Start Failover. Click on the demo link to download the demo and run on your desktop, use the control at the bottom of the demo screen to initiate demo.