MAA - Oracle 10gR2 Redo Transport and Network Best Practices

More documents

Recommendations

Info

Maximum Availability Architecture cursors over time to spread out the cost of recompilation, to avoid a spike in cursor invalidations that causes a lot of contention in OLTP systems. Oracle recommends setting it to FALSE so that new statistics cause the invalidation of cursors that are dependent on them. This is a general best practice for Data Warehouse systems as it keeps query plans in lock-step at all times whether there are one or more active standby databases in the configuration. Note: The above is a general best practice for Data Warehouse systems. Do not alter the default behavior of TRUE for OLTP systems since the negative performance impact outweighs the lesser incremental benefit of doing so. • For all workloads, both data warehouse and OLTP, utilize best practices to minimize apply lag between primary and standby databases. This is important because statistics and other performance information are propagated in the redo stream to the active standby database. Redo Apply performance is optimized using the Redo transport should be optimized using Data Guard Redo Transport and Network Configuration best practices: http://download.oracle.com/docs/cd/B28359_01/server.111/b28282/configbp 006.htm - ABC3636807SRI1 Redo Apply performance should also be monitored and tuned as described in the previous sections of this paper. Monitor Performance – Ad-Hoc Queries The above recommendations address pro-active tuning for standard queries. To the extent that periodically running read-only workloads on the primary database will collect statistics for ad-hoc queries, the recommendations also enable a degree of proactive tuning for ad-hoc workloads. To completely address requirements for ad hoc queries, however, it is necessary to monitor performance, identify problematic queries, and take corrective actions when needed that are appropriate for an active standby database. Monitor standby performance using the following tools: Standby Statspack and Active Session History As a starting point, use Standby Statspack (see My Oracle Support Note 454848.1) and In-Memory ASH to identify Top SQL (by CPU, Elapsed Time, Buffer Gets, etc.). • Standby Statspack can be used to periodically analyze where database time is being spent. Identify poorly performing queries from Standby Statspack using the Top SQL sections ('SQL ordered by CPU', 'SQL ordered by Elapsed Oracle Active Data Guard: Oracle Data Guard 11g Page 35
Maximum Availability Architecture Time'). You may also generate a report on a specific SQL Hash ID, for more information see My Oracle Support Note 1081044.1 • Monitor real-time query performance using Active Session History (ASH). Real-time stats can be collected on an Active Data Guard 11g Release standby database using in-memory ASH. ASH reports provide analysis of transient performance problems that typically last for a few minutes. ASH also performs scoped or targeted performance analysis by various dimensions or their combinations, such as time, session, module, action, or SQL_ID For documentation on ASH see: http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/autostat.htm - PFGRF94211 To generate an ASH report on a physical standby instance, the standby database must be opened read-only. The ASH data on disk represents activity on the primary database and the ASH data in memory represents activity on the standby database. You must specify whether to generate the report using data sampled from the primary or standby database: You are running ASH report on a Standby database. To generate the report over data sampled on the Primary database, enter 'P'. Defaults to 'S' - data sampled in the Standby database. Enter value for stdbyflag: Using Primary (P) or Standby (S): S In the example above, the default value of Standby (S) is selected. Note: See My Oracle Support Note 1081055.1 for information needed to enable ASH for Active Data Guard 11g. Real-Time SQL Monitoring Active Report Beginning with Oracle Database 11g Release 2 (11.2.0.2) you may use Real-Time SQL Monitoring Active Report for a particular execution of long running SQL (accruing more than 5s of CPU or I/O) with Active Data Guard standby databases. SQL monitor active reports can be generated directly from EM live UI while viewing a detailed SQL monitor report. There (see save/send e-mail buttons on the top right of that page), the SQL monitor detail page can be either saved or sent by Oracle Active Data Guard: Oracle Data Guard 11g Page 36
Page 1 and 2: Maximum Availability Architecture O
Page 3 and 4: Maximum Availability Architecture I
Page 5 and 6: Maximum Availability Architecture
Page 7 and 8: Maximum Availability Architecture A
Page 9 and 10: Maximum Availability Architecture o
Page 11 and 12: Maximum Availability Architecture v
Page 13 and 14: Maximum Availability Architecture F
Page 15 and 16: Maximum Availability Architecture S
Page 17 and 18: Maximum Availability Architecture u
Page 19 and 20: Maximum Availability Architecture M
Page 21 and 22: Maximum Availability Architecture r
Page 23 and 24: Maximum Availability Architecture m
Page 29 and 30: Maximum Availability Architecture A
Page 35: Maximum Availability Architecture A
Page 41: Oracle Active Data Guard Oracle Dat

MAA - Oracle 10gR2 Redo Transport and Network Best Practices

Create successful ePaper yourself

Delete template?

Save as template?