Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OUGN winning performnace challenges in oracle Multitenant
Similar to OUGN winning performnace challenges in oracle Multitenant (20)
Recently uploaded
Recently uploaded (20)
OUGN winning performnace challenges in oracle Multitenant
- 1. Winning Performance Challenges in Oracle 12c Multitenant Pini Dibask, Product Manager for Database Solutions March 9th, 2017
- 2. Confidential2 • Pini Dibask, Product Manager, Database Solutions (Quest) • Oracle DBA since 2006 • Oracle Certified Professional DBA (OCP) • My Blog: OracleDBPro.BlogSpot.com Pini.Dibask@Quest.com http://Linkedin.com/in/pinidibask @pini_dibask About Me
- 3. Confidential3 About • Quest is now an independent company again! • #1 independent software company for Database Tools • Driven by innovation “Spend less time on what you need to do, and more time on what you want to do!” • Committed to providing great products and superior support
- 4. Confidential4 Agenda • Introduction to Oracle Multitenant • Ensuring QoS in Multitenant Environments • RAC and Multitenant • Performance Monitoring for Multitenant Environments
- 5. Introduction to Oracle Multitenant Architecture
- 6. Confidential6 Database Consolidation - Prior to Oracle 12c Server Consolidation Multiple databases reside on a single server
- 7. Confidential7 Database Consolidation - Prior to Oracle 12c (Cont’d) Database Consolidation Single database with multiple schemas
- 8. Confidential8 Database Consolidation with Schema Separation - Challenges Name Collisions Same schema name or same public synonym name Security DBA can access data of both applications Upgrades You cannot patch/upgrade only one schema Point-In-Time Recovery Impossible to perform schema level point-in-time recovery
- 9. Confidential9 Pluggable Database Self-contained Oracle database Root Container Oracle-supplied metadata Oracle 12c – Multitenant Architecture
- 10. Confidential10 Oracle 12c – Multitenant Architecture One SGA One set of background processes One root container Multiple pluggable databases Up to 252 PDBs (12cR1) Up to 4096 PDBs (12cR2)
- 11. Confidential11 Oracle 12c – Multitenant Architecture (Cont’d) Pluggable Databases share the following files: Undo Tablespace (optional) Redo Logs Control Files (S)Pfile Local undo introduced in 12cR2
- 12. Confidential12 CDB Level vs. PDB-Level CDB-Level • Oracle Software • SGA & Background Processes • Data Guard • Some Parameters (IsPDB_Modifiable= 'FALSE') • Control Files, Redo • (S)Pfile, Password File PDB-Level • FLUSH SHARED_POOL • FLUSH BUFFER_CACHE • RMAN Backups/Restores • Some Parameters (IsPDB_Modifiable= 'TRUE') • Undo Tablespace (12cR2) • Character Set (12cR2) • Flashback Database (12cR2)
- 13. Confidential13 Multitenant Advantages - Unplug/Plug Moving PDB from one container to another is straightforward s
- 14. Confidential14 Multitenant Advantages - Fast Cloning Clone PDB from another PDB within the same CDB Requires source PDB to be open read only (12cR1) s Hot Clone is available in 12cR2
- 15. Confidential15 Multitenant Advantages - Fast Cloning (Cont’d) Clone PDB from another PDB in remote CDB Requires source PDB to be OPEN READ ONLY (12cR1) Hot Clone is available in 12cR2 s
- 16. Confidential16 Multitenant Advantages - Easy Replication (12c Release 2) Refreshable PDB – Allows manually/automatically refreshing contents of a remotely cloned PDB s
- 17. Confidential17 Oracle 12c – DBCA Non-CDB Single Tenant / Multitenant
- 18. Confidential18 Oracle 12c – Deployment Options Why use Single Tenant instead of Non-CDB? Unplug/Plug Fast Cloning but most importantly … (source: Oracle 12c Release 2 Documentation)
- 19. Ensuring High Level of QoS in Multitenant Environments
- 20. Confidential20 QoS Challenges – Multitenant Environments PDB-Level QoS challenge Allocation of resources among competing sessions Example: One session consumes too many resources CDB-Level QoS challenge Allocation of resources among competing PDBs Example: One PDB consumes too many resources
- 21. Confidential21 Oracle Resource Manager - The Basics (Pre 12c) Resource Manager Elements Resource Plan Resource Plan Directive Consumer Group Resource Plan “WEEKEND” Directive 1 70% of CPU Directive 2 20% of CPU Directive 3 10% of CPU Consumer Group “WAREHOUSE” Consumer Group “OLTP” Consumer Group “OTHERS_GROUPS”
- 22. Confidential22 The Solution - Oracle Resource Manager PDB-Level Resource Plan Specifies how resources are allocated to consumer groups Prioritize resources between competing sessions CDB-Level Resource Plan Specifies how resources are allocated to PDBs Prioritize resources between competing PDBs
- 23. Confidential23 Oracle Resource Manager - 12c Multitenant CDB Resource Plan Directive CPU Shares CPU Utilization Limit Parallel Servers Limit Example Pluggable Database CPU Shares Guaranteed CPU CPU Limit Parallel Servers Limit OLTP 3 3/4 = 75% 100% 100% DWH 1 1/4 = 25% 60% 100%
- 24. Confidential24 Oracle Resource Manager - 12c Multitenant Obtain information about default CDB resource plan Obtain information about default PDB directive s s
- 25. Confidential25 Example of CDB-Level Resource Plan Resource Plan “Daytime_CDB_PLAN” PDB “OLTP” PDB “DWH” Directive 2 Guaranteed CPU: 25% Maximum CPU: 60% Directive 1 Guaranteed CPU: 75% Maximum CPU: 100% Pluggable Database CPU Shares Guaranteed CPU CPU Limit Parallel Servers Limit OLTP 3 3/4 = 75% 100% 100% DWH 1 1/4 = 25% 60% 100%
- 26. Confidential26 s Creating CDB Resource Plan Pluggable Database CPU Shares Guaranteed CPU CPU Limit OLTP 3 3/4 = 75% 100% DWH 1 1/4 = 25% 60%
- 27. Confidential27 s Creating CDB Resource Plan (Cont’d)
- 28. Confidential28 Enabling/Disabling CDB Resource Plan Manually enabling resource plan Manually disabling resource plan s s
- 29. Confidential29 Enabling/Disabling CDB Resource Plan (Cont’d) s Automatically Enable/Disable CDB Resource Plan
- 30. Confidential30 PDB Level Memory Resource Management Not available in 12c Release 1 12c Release 2 - Memory parameters can be set at PDB level SGA_TARGET DB_CACHE_SIZE DB_SHARED_POOL_SIZE PGA_AGGREGATE_LIMIT PGA_AGGREGATE_TARGET SGA_MIN_SIZE New in 12c Release 2
- 31. Confidential31 PDB Level I/O Resource Management Not available in 12c Release 1 12c Release 2 Introduced the following new parameters: MAX_IOPS - limits number of I/O operations per second MAX_MBPS - limits megabytes for I/O operations per second Default : 0 (no limit) If Oracle waits due to I/O limit “resmgr: I/O rate limit” wait event will appear Cannot be set in a Non CDB
- 32. Confidential32 How Many Resources Actually Being Used by PDBs? Option #1 - DBA_HIST_RSRC_PDB_METRIC Displays historical resource manager metrics by PDB Option #2 - AWR_ROOT_RSRC_PDB_METRIC (underlying AWR table) Option #3 - AWR Reports
- 33. Confidential33 Maintenance Tasks in Oracle Multitenant ENABLE_AUTOMATIC_MAINTENANCE_PDB parameter Can be used to enable/disable running of maintenance tasks Default: true Can be set at either CDB or PDB levels AUTOTASK_MAX_ACTIVE_PDBS parameter Maximum number of PDBs that can schedule maintenance tasks concurrently Default: 2 (two PDBs and the CDB root can run tasks at the same time) Can be set at CDB level only Both parameters introduced in 12c Release 2
- 35. Confidential35 Why RAC & Multitenant? Single Instance & Multitenant challenges Not Scalable = Limited Consolidation Solution Instance Down Downtime for all PDBs RAC makes Multitenant better Scalable = True consolidation solution Available = Instance Down PDBs continue running on other nodes
- 36. Confidential36 RAC & Multitenant s Multitenant fully supports RAC PDBs can be opened on specific instances
- 37. Confidential37 RAC & Multitenant PDBs workload distributed across RAC instances Services Single SGA per CDB Instance Node1 CDB Instance 1 Node2 CDB Instance 2 Multitenant Container Database (CDB)
- 38. Confidential38 RAC & Multitenant PDBs workload distributed across RAC instances Services Single SGA per CDB Instance Node1 CDB Instance 1 Node2 CDB Instance 2 Node3 CDB Instance 3 Multitenant Container Database (CDB)
- 39. Confidential39 RAC & Multitenant s Preferred Instance Available Instance PDB opened only in Preferred instance
- 40. Performance Monitoring for Multitenant Environments
- 41. Confidential41 Multitenant & AWR – Oracle 12c Release 1 Snapshots taken only at CDB-Level AWR data reside in cdb$root container
- 42. Confidential42 Multitenant & AWR – Oracle 12c Release 1 (Cont’d) s
- 43. Confidential43 AWR reports are available only at CDB level AWR Management Operations only at CDB level AWR data retention Snapshot schedule Taking manual snapshots Purging snapshot data Unplugged PDB does not contain AWR information Multitenant & AWR – Oracle 12c Release 1 (Cont’d)
- 44. Confidential44 Multitenant & AWR – Oracle 12c Release 1 (Cont’d)
- 45. Confidential45 Multitenant & AWR – Oracle 12c Release 2 Snapshots can be taken either at CDB or PDB level Snapshot data reside in SYSAUX tablespace of each PDB It is possible to create a report at PDB-level AWR report AWR management operations at either CDB or PDB level New Parameter : AWR_PDB_AUTOFLUSH_ENABLED Specifies whether to enable automatic AWR snapshots for PDBs Default : false (automatic AWR snapshots are disabled for PDBs) Can be set at CDB or PDB level
- 46. Confidential46 Multitenant & AWR – Oracle 12c Release 2 (Cont’d)
- 47. Confidential47 Workload Analysis using OEM ASH Analytics
- 48. Confidential48 Workload Analysis using Foglight for Oracle
- 49. Confidential49 Workload Analysis using Foglight for Oracle
- 50. Confidential50 Workload Analysis using Foglight for Oracle
- 51. Confidential51 References Introduction to the Multitenant: Architecture (Documentation) http://docs.oracle.com/database/122/CNCPT/introduction-to-the-multitenant-architecture.htm#CNCPT89234 Oracle Multitenant (White Paper) http://www.oracle.com/technetwork/database/multitenant-wp-12c-1949736.pdf Oracle Multitenant: New Features in Oracle Database 12c Release 12 (White Paper) http://www.oracle.com/technetwork/database/multitenant/overview/multitenant-wp-12c-2078248.pdf Note: All diagrams and illustrations are used by permission of Oracle
- 52. Q&A
- 53. Thank You!
Editor's Notes
- Me, I’ve been an Oracle DBA since 2006, during these years I worked a DBA and DBA team leader and as mentioned currently I work as a Product Manager for Database Solutions at Quest. I’m based in Israel Tel Aviv where we have a development group for some of our Database monitoring solutions including Foglight and Spotlight that some of you are probably familiar with. I’m an Oracle Certified Professional. You can see here my blog where I write about my experience of working with Oracle Databases. You can also find below my email, LinkedIn and twitter addresses so if you’d like to contact me you’d be more than welcome.
- I assume that you probably all familiar with Quest, the company which develops some of the most popular Database tools in the industry like Toad. Quest was actually acquired by Dell a few years ago but now – actually 2 weeks ago Quest became an independent software company again so we are very excited about that. The new quest is driven by innovation probably more than ever before and focused on analytics, and SaaS solutions. Our goal is basically make DBAs spend less time on what they need to do and more time on what the want to do. Quest is committed to providing great products and superior support. So that’s about all on myself and Quest – let’s move on to the agenda for today’s session.
- I assume that you probably all familiar with Quest, the company which develops some of the most popular Database tools in the industry like Toad. Quest was actually acquired by Dell a few years ago but now – actually 2 weeks ago Quest became an independent software company again so we are very excited about that. The new quest is driven by innovation probably more than ever before and focused on analytics, and SaaS solutions. Our goal is basically make DBAs spend less time on what they need to do and more time on what the want to do. Quest is committed to providing great products and superior support. So that’s about all on myself and Quest – let’s move on to the agenda for today’s session.
- A common approach in the past was to take different databases from different machines, and consolidate them into one machine. In this example we can see separate 3 machines with a single database on each. We could have consolidate them into a single machine. This approach allows us to consolidate servers which is good from IT resources management, but we didn’t consolidate databases. We would still have to manage different databases. 3 different databases to backup, 3 different databases to upgrade, 3 databases to monitor, etc.
- A better approach would be to consolidate many different databases into a single database, where each database has its own schema for example. Now, we need to manage only one Oracle Database. The problem with this approach is that there are several challenges when doing database consolidation, let’s review some of them.
- A better approach would be to consolidate many different databases into a single database, where each database has its own schema for example. Now, we need to manage only one Oracle Database. The problem with this approach is that there are several challenges when doing database consolidation, let’s review some of them.
- In a multitenant architecture, these is one instance with many pluggable databases. Each Pluggable Database is a self-contained, independent Database with its own schemas, data, etc. Pluggable Database is a “regular” Database from the application standpoint. In addition, there is one root container which stores Oracle-metadata that is shared across all the PDBs like PL/SQL packages, for example, the DBMS_SYSTEM package. All the PDBs can be plugged into the root container.
- You can configure a CDB to use local undo in every container or to use shared undo for the entire CDB. A CDB can run in local undo mode or shared undo mode. You can specify the undo mode of a CDB during CDB creation in the ENABLE PLUGGABLE DATABASE clause of the CREATE DATABASEstatement. You can change the undo mode of a CDB after it is created by issuing an ALTER DATABASE statement and restarting the CDB. The undo mode applies to the entire CDB. Therefore, every container either uses shared undo or local undo.
- Some parameter are modifiable at CDB level and some at PDB level. CDB-Level example: SGA_TARGET UNDO_RETENTION and UNDO_TABLESPACE PDB-LEVEL example: STATISTICS_LEVEL
- This new feature allows to have a cloned PDB that can be refreshed from another PDB either manually (on-demand) or automatically (scheduled refresh). The way this works is by creating a full clone at first stage (which can be taken with no downtime now with the new 12cR2 hot clone feature), and then there is no need to perform a full clone again because this feature allows applying incremental redo since the last clone or the last refresh time. This could be very useful in scenarios that the source PDB is very large and we would like to avoid creating a full clone to the entire PDB from scratch every time, because this process takes a long time when the PDB is very large. By having to apply only the incremental redo since last refresh or last clone, the process of having up to date cloned PDB for dev/test purposes becomes much faster and easier.
- Oracle 12c introduced new QoS challenges when it comes to the new Multitenant architecture. For example, One or more PDBs consume too many resources. Another example is that a single PDB has an inconsistent performance because the other PDBs are competing for system resources at various times
- The Resource Plan Specifies how resources are allocated to the different consumer groups by using plan directives. Consumer group is a collection of user sessions grouped together by a common attribute, such as username, program, service, and so on. In this example we can see that: The 1st plan directive allocates 70% of CPU to the WAREHOUSE consumer group The 2nd plan directive allocates 20% of CPU to the OLTP consumer group The last plan directive allocates 10% of CPU to all the other sessions
- Oracle 12c introduced new QoS challenges when it comes to the new Multitenant architecture. For example, One or more PDBs consume too many resources. Another example is that a single PDB has an inconsistent performance because the other PDBs are competing for system resources at various times
- CPU Shares – The proportion of the CPU resources guaranteed to the PDB CPU Utilization Limit – % of the CDB available CPU that is available for the PDB Parallel Servers Limit – % of the CDB available parallel servers that are available for the PDB
- The Resource Plan Specifies how resources are allocated to the different consumer groups by using plan directives. Consumer group is a collection of user sessions grouped together by a common attribute, such as username, program, service, and so on. In this example we can see that: The 1st plan directive allocates 70% of CPU to the WAREHOUSE consumer group The 2nd plan directive allocates 20% of CPU to the OLTP consumer group The last plan directive allocates 10% of CPU to all the other sessions
- The Resource Plan Specifies how resources are allocated to the different consumer groups by using plan directives. Consumer group is a collection of user sessions grouped together by a common attribute, such as username, program, service, and so on. In this example we can see that: The 1st plan directive allocates 70% of CPU to the WAREHOUSE consumer group The 2nd plan directive allocates 20% of CPU to the OLTP consumer group The last plan directive allocates 10% of CPU to all the other sessions
- The first step in creating the Resource plan is to create a Pending Area, which is a temporary work area for Resource Management configuration. changes in the pending area are not visible until the pending area is submitted. Click Now we create the 1st CDB Plan directive which allocates 3 CPU shares, and allows maximum 100% CPU resources to the OLTP pluggable database Click The next step is to create the 2nd CDB Plan directive which allocates 1 CPU share, and allows maximum 60% CPU resources to the DWH pluggable database Click In the last step we will validate the pending area and submit it
- The first step in creating the Resource plan is to create a Pending Area, which is a temporary work area for Resource Management configuration. changes in the pending area are not visible until the pending area is submitted. Click Now we create the 1st CDB Plan directive which allocates 3 CPU shares, and allows maximum 100% CPU resources to the OLTP pluggable database Click The next step is to create the 2nd CDB Plan directive which allocates 1 CPU share, and allows maximum 60% CPU resources to the DWH pluggable database Click In the last step we will validate the pending area and submit it
- The first step in creating the Resource plan is to create a Pending Area, which is a temporary work area for Resource Management configuration. changes in the pending area are not visible until the pending area is submitted. Click Now we create the 1st CDB Plan directive which allocates 3 CPU shares, and allows maximum 100% CPU resources to the OLTP pluggable database Click The next step is to create the 2nd CDB Plan directive which allocates 1 CPU share, and allows maximum 60% CPU resources to the DWH pluggable database Click In the last step we will validate the pending area and submit it
- The first step in creating the Resource plan is to create a Pending Area, which is a temporary work area for Resource Management configuration. changes in the pending area are not visible until the pending area is submitted. Click Now we create the 1st CDB Plan directive which allocates 3 CPU shares, and allows maximum 100% CPU resources to the OLTP pluggable database Click The next step is to create the 2nd CDB Plan directive which allocates 1 CPU share, and allows maximum 60% CPU resources to the DWH pluggable database Click In the last step we will validate the pending area and submit it
- We’ve covered CPU level resource management – now let’s see how we can manage to address memory resource management challenges
- A large amount of disk I/O can cause poor performance. Several factors can result in excess disk I/O, such as poorly designed SQL or index and table scans in high-volume transactions. If one PDB is generating a large amount of disk I/O, then it can degrade the performance of other PDBs in the same CDB. DBWR I/Os, control file I/Os, password file I/Os and other critical I/Os are exempted from the rate limit set by these parameters, but their I/Os are accounted for while throttling. Because of these exemptions, the PDB's actual I/O rate may sometimes exceed the limit. Use one or both of the following initialization parameters to limit the I/O generated by a particular PDB: The MAX_IOPS initialization parameter limits the number of I/O operations for each second. The MAX_MBPS initialization parameter limits the megabytes for I/O operations for each second. Both limits are enforced if you set both initialization parameters for a single PDB. If these initialization parameters are set with the CDB root as the current container, then the values become the default values for all of the containers in the CDB. If they are set with an application root as the current container, then the values become the default values for all of the application PDBs in the application container. When they are set with a PDB or application PDB as the current container, then the settings take precedence over the default settings in the CDB root or the application root. These parameters cannot be set in a non-CDB. The default for both of these initialization parameters is 0 (zero). If these initialization parameters are set to 0 (zero) in a PDB, and the CDB root is set to 0, then there is no I/O limit for the PDB. If these initialization parameters are set to 0 (zero) in an application PDB, and its application root is set to 0, then there is no I/O limit for the application PDB. Critical I/O operations, such as ones for the control file and password file are exempted from the limit and continue to run even if the limit is reached. However, all I/O operations, including critical I/O operations, are counted when the number of I/O operations and the megabytes for I/O operations are calculated.
- We’ve covered to define various resource limits to pluggable databases such as memory, cpu, and disk I/O limits. One question you may ask is how would you even know how many resources are actually being used today in order to define limits? DBA_HIST_RSRC_PDB_METRIC displays information about historical Resource Manager metrics for the past hour by PDB.
- Automated maintenance tasks are tasks that are started automatically at regular intervals to perform maintenance operations on the database. An example is a task that gathers statistics on schema objects for the query optimizer. Automated maintenance tasks run in maintenance windows, which are predefined time intervals that are intended to occur during a period of low system load. You can customize maintenance windows based on the resource usage patterns of your database, or disable certain default windows from running. You can also create your own maintenance windows. Oracle Database has these predefined automated maintenance tasks: Automatic Optimizer Statistics Collection—Collects optimizer statistics for all schema objects in the database for which there are no statistics or only stale statistics. The statistics gathered by this task are used by the SQL query optimizer to improve the performance of SQL execution. Optimizer Statistics Advisor—Analyzes how statistics are being gathered and suggests changes that can be made to fine tune statistics collection. Automatic Segment Advisor— Identifies segments that have space available for reclamation, and makes recommendations on how to defragment those segments. You can also run the Segment Advisor manually to obtain more up-to-the-minute recommendations or to obtain recommendations on segments that the Automatic Segment Advisor did not examine for possible space reclamation. Automatic SQL Tuning Advisor—Examines the performance of high-load SQL statements, and makes recommendations on how to tune those statements. You can configure this advisor to automatically implement SQL profile recommendations.
- Now we create a new Administrator-managed service named “svc_pdbtest” that has instance O121RAC2 as preferred and O121RAC1 as available
- In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment. +++++++ In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
- In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment. +++++++ In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
- Here you can see the implications of the way AWR works in Oracle 12cR1 AWR Management Operations only at CDB level AWR data retention Snapshot schedule Taking manual snapshots Purging snapshot data
- In Oracle Database 12c Release 1 (12.1.01), a centralized Automatic Workload Repository (AWR) stores the performance data related to CDB and PDBs in a multitenant environment. You can take an AWR snapshot only at a CDB-level, that is, on the CDB root. This AWR snapshot is for the whole database system, that is, it contains the statistical information about the CDB as well as all the PDBs in a multitenant environment. +++++++ In Oracle Database 12c Release 2 (12.2), CDB root as well as individual PDBs store, view, and manage AWR data. You can take an AWR snapshot at a CDB-level, that is, on the CDB root, as well as at a PDB-level, that is, on the individual PDBs.
- The default value of AWR_PDB_AUTOFLUSH_ENABLED is false. Thus, by default, automatic AWR snapshots are disabled for all the PDBs in a CDB. When you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root, the new value takes effect in all the PDBs in the CDB. Therefore, if you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root to true, the value of AWR_PDB_AUTOFLUSH_ENABLED is also changed to true in all of the PDBs, so that automatic AWR snapshots are enabled for all the PDBs. You can also change the value of AWR_PDB_AUTOFLUSH_ENABLED in any of the individual PDBs in a CDB, and the value that is set for each individual PDB will be honored. This enables you to enable or disable automatic AWR snapshots for individual PDBs. When a new PDB is created, or a PDB from a previous database release is upgraded to the current database release, automatic AWR snapshots are enabled or disabled for the PDB based on the current value of AWR_PDB_AUTOFLUSH_ENABLED in the root.
- The default value of AWR_PDB_AUTOFLUSH_ENABLED is false. Thus, by default, automatic AWR snapshots are disabled for all the PDBs in a CDB. When you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root, the new value takes effect in all the PDBs in the CDB. Therefore, if you change the value of AWR_PDB_AUTOFLUSH_ENABLED in the CDB root to true, the value of AWR_PDB_AUTOFLUSH_ENABLED is also changed to true in all of the PDBs, so that automatic AWR snapshots are enabled for all the PDBs. You can also change the value of AWR_PDB_AUTOFLUSH_ENABLED in any of the individual PDBs in a CDB, and the value that is set for each individual PDB will be honored. This enables you to enable or disable automatic AWR snapshots for individual PDBs. When a new PDB is created, or a PDB from a previous database release is upgraded to the current database release, automatic AWR snapshots are enabled or disabled for the PDB based on the current value of AWR_PDB_AUTOFLUSH_ENABLED in the root.