Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
Oracle (RAC) Database Consolidation Registered vs. Running • Registered databases and instances could Registered: potentially start and run at the same time. • n DB instances
are defined to run on a machine • Oracle’s Quality of Service Management (potentially) or scripts can be used to model policies to run certain databases only at certain times; e.g. geographic region over time vs.
• Assume the cluster is PST based: Running: • EMEA based DBs run 10:00pm – 8am PST • Registered databases • APAC based DBs run 6:00pm – 3am PST and instances are (concurrently) running • USA based DBs run 8:00am – 6pm PST (active workload)
Database Consolidation One instance per server as the basis • An Oracle database by default assumes that there is only one database instance running on the server: • Instance parameters are based on this assumption • Consolidation changes that premise
• Use Hugepages, if possible – details: 80% DB • MOS notes 361323.1 and 401749.1
• For OLTP applications: • SUM (sga_target + pga_aggregated_target) <= 80% of physically available memory per DB server 20% OS • For DW / BI applications: • SUM (sga_target + 3* pga_aggregated_target) <= 80% of physically available memory per DB server
Database Consolidation Recommendation 2: Use CPU_COUNT to “cage instances” • CPU usage should be regulated. • The OS scheduler schedules CPU as requested by each individual instance. • The OS scheduler does not know about the
priority of the various instances on the server. B
28 28 • Most backgrounds are not managed 24 24 • Critical and use very little CPU 20 20 • MMON, Job Scheduler slaves are managed Instance D: 8 CPUs 16 16
Instance D: 4 CPUs • No CPU affinity 12 12 Instance C: 6 CPUs Instance C: 4 CPUs • Not meant for hard-partitioning or licensing 8 8 • Instance B: 4 CPUs Instance B: 4 CPUs All CPUs may be used 4 4 • CPU utilization averaged across all CPUs ≤ 25% Instance A: 4 CPUs Instance A: 4 CPUs
Database Consolidation Over-Provisioning Approach – It’s still hardware that’s the limit • Best used for non-critical 140 120 databases that are typically 100 80 well-behaved – examples: CPU Util. 60 Average • 40 Complimentary workload 20 • 0 Systems with little contention t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 for CPU if database instances 32 16 CPUs are sufficiently loaded.
Oracle RAC based Consolidation Background for LMS Real Time (RT) Process recommendation • The number of LMS RT processes per instance is determined by a function on CPU_COUNT. • In order to guarantee optimized
C1 C2 performance and reliability, the DB DB general rule of thumb for RAC is:
B1 B2 • The aggregated number of LMS DB DB RT processes per server should
Oracle RAC based Consolidation Cluster Limits – Starting DBs are currently the main concern • In most cases, per server limits will be Starting: reached before cluster limits are reached. • Registered databases and instances start • Cluster limits apply to: • Default is “starting • at the same time”. Registered resources (databases)
• Starting databases in the cluster – reason: B1 D1 B2 D2 DB DB DB DB • Starting databases need to register
A1 C1 A2 C2 with the cluster (Oracle Clusterware). DB DB DB DB • Currently and for example, 100 Clusterware Clusterware starting Oracle RAC databases OS OS on a 4 node cluster are supported. • The Number assumes each Oracle RAC database uses an instance on each node. Cluster Limits
(Oracle RAC) Database Consolidation Summary • For a successful database consolidation, consider the following as rules of thumb: Existing Workload
ion 80% 1. General considerations for capacity planning at DB iliz Average t U 2. Manage Memory carefully (and dynamically) Time OS 3. Use CPU_COUNT + 20% 4. Use DB Resource Manager Data Structures 5. Over-provision only based on CPU_COUNT Concurrency