Data Guard Protection From Lost-Write Corruption
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

Automatic Block Repair at a Primary Database - Active Data Guard
This demonstrates how Active Data Guard 11g Release 2 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.

Automatic Block Repair at a Standby Database - Active Data Guard
This demonstrates how Active Data Guard 11g Release 2 will also 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.

Data Guard Broker
This demonstrates latest capabilities in Oracle Database 11.2.0.3 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. Click here Data Guard Broker Documentation.

Production Offload - Oracle Active Data Guard
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.

Data Pump and Standby Statspack - Active Data Guard
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. 

Query Service Level Agreement - Active Data Guard
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.

DML Redirection - Active Data Guard
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 11g Release 2. 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. 

Failover of PeopleSoft Application along with Data Guard Fast-Start Failover
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.

Data Guard Fast-Start Failover - Automatic Database Failover for High Availability in an MAA Configuration
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 .

Database Rolling Upgrades using Physical Standby Databases - Oracle Database 11g
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, new in Data Guard 11g. 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). Click here for MAA best practices and information on a script available on My Oracle Support that further simplifies the transient logical rolling upgrade process.

Extended Datatype Support for SQL Apply and Streams
Extended Datatype Support (EDS) enables SQL Apply and Streams to replicate changes to tables that contain datatypes not natively supported from one database to another.  Without EDS, only the tables that contain natively supported datatypes can be replicated. Click here for more details in the accompanying MAA best practices paper.

This demonstrates a patch being applied online to Oracle Database 11g in order to achieve continuous and uninterrupted database service. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo .   Click here for the accompanying presentation of MAA best practices and capabilities included with the Oracle Database to minimize planned downtime during software upgrades.

This demonstrates Oracle Beehive 1.5 running on Exadata Database Machine under a 3,000 user load. The demonstration uses a two-node Oracle RAC database with two Oracle Beehive application servers front-ended by an F5 Big-IP Local Traffic Manager. There is also a local two-node Oracle Data Guard physical standby database that provides both data protection and an additional level of high availability (HA). The HA standby database is synchronized with the primary using Data Guard real-time apply. During the demonstration we crash the primary and failover to the standby database. End-users see a pause in functionality while Beehive application servers automatically disconnect from the crashed primary and reconnect to the new primary database via Fast Application Notification (FAN) and Fast Connection Failover (FCF). The failover process takes 30 seconds, then users are able to continue work without the need to reconnect to Beehive. Following failover, the original primary is automatically reinstated as a standby database, and automatically resynchronized with the new primary database. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo. Running time is 5 minutes and 28 seconds.

This demonstrates Oracle Beehive 1.5 running on Exadata Database Machine under a 3,000 user load. The demonstration uses a two-node Oracle RAC database with two Oracle Beehive application servers front-ended by an F5 Big-IP Local Traffic Manager. The database instance on the first Oracle RAC node is aborted - and the demonstration shows how Oracle Beehive clients (email, calendar, conferencing and instant messaging) continue to operate through the failure using the surviving instance on the second Oracle RAC node. Oracle Beehive Services that were connected to the failed instance, are automatically routed and reconnected to the surviving instance using Fast Application Notification and Fast Connection Failover features that are integrated into Oracle Beehive. Oracle RAC node or instance failure is transparent to the Oracle Beehive users. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo. Running time is 6 minutes and 27 seconds.

This demonstrates a completely automated site failover for an MAA configuration of E-Business Suite Release 12 running under load.  Data Guard Fast-Start Failover automates database failover. A role change trigger fires at failover time - and executes an E-Business Suite failover script that removes the topology, runs AutoConfig on the database and application tiers, and restarts the application.  The network is switched via a DNS push, users are routed to the new production site and login.  The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo . Click here for the accompanying presentation that provides more details of the MAA best practices utilized in this demonstration.

Siebel 8.1 RAC Instance Failover
This demonstrates Siebel 8.0 This demonstrates Siebel 8.1 running under load on a four-node Oracle 11g Release 2 RAC cluster.  The Oracle instance on the first node is aborted - and the demonstration shows the surviving instances perform recovery, Siebel Servers reconnect automatically and are routed to the surviving instance, Oracle Transparent Application Failover reconstructs the database sessions and users continue processing. RAC node failure is transparent to the Siebel user. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo.

Siebel 8.1 Local Data Guard Failover
This demonstrates Siebel 8.1 running under load on an Oracle 11g Release 2 primary database with local standby .  The primary database is aborted - and the demonstration shows the failover to the standby, Siebel Servers reconnect automatically and are routed to the surviving database, Oracle Transparent Application Failover reconstructs the database sessions and users continue processing. The primary node failure is transparent to the Siebel user. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo.

Siebel 8.0 RAC Instance Failover
This demonstrates Siebel 8.0 running under load on a two-node Oracle RAC cluster.  The Oracle instance on the first node is aborted - and the demonstration shows the surviving instance perform recovery, Siebel Servers reconnect automatically are are routed to the surviving instance, Oracle Transparent Application Failover reconstructs the database sessions and users continue processing. RAC node failure is transparent to the Siebel user. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo . Click here for the accompanying MAA best practices presentation.

Siebel 8.0 Site Failover - Automatic Application and Database Failover
Similar to the E-Business Suite Site Failure demonstration above, this demo simulates site failure when both primary RAC instances are powered down.  Data Guard Automatic Failover the transition of the standby database at the remote site to the production role.  The role change to production fires a trigger that executes the Siebel failover script. Sieble Gateway, Siebel Servers and Web Servers are started and client connections are switched to the standby site through DNS push. The demo automatically runs in your browser when you click on the demo link - use the control's at the bottom of the demo screen if you prefer to manually advance the demo . Click here for the accompanying MAA best practices presentation.

Siebel 8.0 - Transparent Database Upgrade
The Siebel database is upgraded to a new Oracle release using Data Guard SQL Apply rolling database upgrades.  First a SQL Apply standby database is upgraded to the new release.  Then Oracle Transparent Application Failover (TAF) is used during the switchover to the upgraded database, eliminating the need to restart Siebel.  Siebel users only see a slight pause in processing, then resume work on the new production database operating at the new Oracle release. Click here for the accompanying MAA best practices presentation.

demo1

demo2

Data Recovery Advisor - Repair Block Corruption & Missing Files
These demonstrations show how easy it is to automatically detect and repair database failures with the Data Recovery Advisor (DRA) in Oracle Database 11g. DRA eliminates the DBA time spent analyzing failures and planning an appropriate recovery strategy, by automating the entire process. The first scenario shows how DRA minimizes overall recovery time by automatically identifying block corruptions in real-time and recommending an appropriate recovery strategy. The second scenario shows how DRA facilitates with recovering a down database, by automatically detecting all missing files and recommending a recovery strategy. Each demo is a .exe that can be downloaded and run from your desktop. Click here for more information on DRA and other Backup & Recovery technologies.

Recovery Manager - Fast Recovery with Switch to Copy
This demonstrates how to use Recovery Manager's Switch to Copy Feature to quickly use an existing image copy backup in place of a production data file, eliminating the time to restore the backup. Click here for more information on RMAN and other Backup & Recovery technologies.

Fast Recovery Area Sizing - SQL*Plus
This demonstrates how to use SQL*Plus based queries to help monitor and size the Fast Recovery Area (FRA).

RMAN and Grid Control
This demonstrates scheduling and monitoring RMAN Backups using Enterprise Manager Grid Control.

Fast Recovery Area Sizing - Enterprise Manager
This demonstrates how to use Enterprise Manager based methods to help monitor and size the Fast Recovery Area (FRA).

Flashback Database and Guaranteed Restore Points
This demonstrates how easily Flashback Database can be used with Guaranteed Restore Points in a space-efficient manner to quickly unwind extensive changes made within a database, without needing to use any time consuming traditional point-in-time recovery techniques.

Flashback Drop
This demonstrates how easy it is to recover an object using the Flashback Drop feature. The demonstration shows that even though a table is dropped, it is still stored in a recycle bin. Then, in response to having dropped the object in error, we show how to use the syntax FLASHBACK TABLE <> TO BEFORE DROP, to quickly and easily bring the object back online.

Flashback Table
This demonstration shows how to use Flashback Query for analysis, and then how to use Flashback Table to quickly and easily revert a table to a previous point in time.