Multitenant best practices for Amazon RDS Custom for Oracle
Amazon Relational Database Service (Amazon RDS) Custom for Oracle is a managed database service for legacy, custom, and packaged applications that require access to the underlying operating system and database environment. Amazon RDS Custom now supports the Oracle Multitenant option on Oracle Database version 19c using Enterprise Edition. With this release, an RDS Custom for Oracle DB instance can operate as a multitenant container database (CDB) hosting one or more pluggable databases (PDBs). A PDB is a set of schemas, schema objects, and non-schema objects that logically appears to a client as a non-CDB.
Oracle released the Multitenant option with 12cR1 to help with consolidation (improved resource utilization), manageability (manage many as one), and enhanced availability (during database maintenance). Starting in Oracle Database 21c, a multitenant container database is the only supported architecture.
Oracle Multitenant offers the benefit of consolidating several databases (PDBs) into one (CDB) to achieve better resource utilization, along with the advantage of managing many databases as one. While providing simplicity in managing a single database (backups, patching, high availability, and disaster recovery), it gives isolation for each individual PDB for access and resource limits.
In this post, we discuss the configuration and operational best practices for Oracle Multitenant on Amazon RDS Custom for Oracle to achieve better performance and efficient administration of Oracle Database. We primarily focus on enabling
HugePages, enabling local undo, creating remote clones for PDBs, pluggable database resource management and monitoring tools using Amazon CloudWatch, and how to use CloudWatch alarms for proactive monitoring. This will enable streamlining processes, improve communication and collaboration between teams, and implement effective database management and analytics solutions.
Amazon RDS Custom for Oracle Multitenant will enables the following use cases:
- Only multitenant architecture databases are certified for Oracle E-Business Suite with Oracle Database 19c. Oracle E-Business suite supports the multitenant architecture with a single CDB containing a single PDB. For more information, refer to Oracle E-Business Suite and the Oracle Multitenant Architecture (Doc ID 2567105.1). Oracle E-Business Suite’s requirement of OS access and multitenant architecture makes Amazon RDS Custom for Oracle with the Multitenant option suitable for its use. This will provide you the managed experience you want when running Oracle E-Business Suite on Amazon Elastic Compute Cloud (Amazon EC2) or on premises.
- You can consolidate your lower footprint database workloads. Customers of Amazon RDS Custom for Oracle are provided with smallest instance type with 2 vCPUs for a single PDB multitenant option. We have seen some customers with multiple environments that don’t need 2 vCPUs and can benefit from consolidating such environments further. Amazon RDS Custom for Oracle with the Multitenant option, which allows you to create multiple PDBs, can help with this requirement to optimize cost. This will also help with manageability because many databases can be managed as one.
Define the maximum number of PDBs
The MAX_PDBS parameter (introduced in 12.2) allows you to define the maximum number of PDBs in a CDB.
Oracle Enterprise Edition allows usage of up to three user-created PDBs without requiring an additional license for the Multitenant option. Refer to Features and Licensing for the Multitenant architecture for more details. If you don’t have a license for the Multitenant option, to avoid accidental creation of more than three PDBs in your CDB, set
max_pdbs to 3. See the following code:
To find the user for Oracle installation for your RDS Custom for Oracle instance, you can check the owner of one of the Oracle Database background process. By default it is
rdsdb user. (Note: If you included installation parameters in your CEV manifest, then your DB instance uses the Oracle base, Oracle home, and the ID and name of the UNIX/Linux user and group that you specified.)
The HugePages feature is an integral part of the Linux kernel 2.6. If HugePages is enabled, the operating system can support memory pages greater than the default (4 KB). With HugePages, the page size is configurable (2 MB – 1 GB) depending on kernel version and hardware architecture. With the help of HugePages, memory required for page tables can be lowered and system performance for page access and management is improved. Another benefit is pages are locked in memory and never swapped out. These advantages of HugePages will help improve performance of Oracle Database with a large System Global Area (SGA).
- Use the following code:
The output shows that HugePages isn’t configured on the RDS Custom instance:
HugePages size is defined as 2 MB:
This is the maximum locked-in memory address space in KB.
By default in an RDS Custom for Oracle instance, automatic memory management (AMM) is enabled by setting
memory_target to a non-zero value. By default, it is set to 3/4 of the DB instance class memory (
- In this example, DB instance class memory is 32 GiB, so
memory_max_targetare set to 24 GiB:
To use HugePages, AMM has to be disabled and automatic shared memory management (ASMM) has to be enabled.
To disable AMM, we need to set
memory_max_target to 0. To enable ASMM, we need to set
sga_max_size to non-zero values.
For this example, we set the following:
sga_max_targetto 3/4 of the DB instance class memory: (3/4*32) = 24 GiB
pga_aggregate_targetto 1/8 of the DB instance class memory: (1/8*32) = 4 GiB
- Use the following code:
- The following command pauses Amazon RDS Custom automation for 90 minutes:
Once modified, the status of the instance shows as automation-paused:
- Restart the database instance:
- Log in as root (you can do it via
ssm-user or ec2-user):
hugepages_settings.shas per My Oracle Support note 401749.1:
The alert log shows the following while starting the instance:
- Resume automation using the console or AWS CLI:
Once modified, the status of the instance shows as available:
Enable local undo
A container database can run in local undo mode or shared undo mode. Local undo mode means that every container in the CDB uses its own undo tablespace. Shared undo mode means that there is one active undo tablespace per instance of a single-instance CDB.
By default, a container database is in shared undo mode.
Local undo mode provides increased isolation for each container and improves the efficiency of some operations, such as unplugging the container or performing point-in-time recovery on the container. In addition, local undo mode is required for some operations to be supported, such as relocating a PDB or cloning a PDB that is in open read/write mode.
Complete the following steps to enable local undo:
- Make sure
undo_managementis set to AUTO (this is the default value for RDS Custom for Oracle instances).
- Query dictionary view
DATABASE_PROPERTIESto find the value for property
- To enable local undo, shut down the CDB:
- Startup in upgrade mode:
- Enable local undo:
- Shut down and restart the CDB instance:
- Verify the property
The local undo capability is important in remote PDB cloning because it allows for the creation of a new PDB from an existing one, without affecting the original data. The local undo feature in PDB cloning helps ensure the data integrity of the original PDB, as well as the consistency of the newly created PDB. This will be very helpful in some use cases.
Let’s say you have multiple pluggable databases in your production environment and you want to clone one or more PDBs from your production environment on Amazon RDS Custom for Oracle to another test environment running on Amazon RDS Custom for Oracle. This will eliminate the need for restoring the entire snapshot for Amazon RDS Custom for Oracle, which will save time and resources. You can remote clone the production copy of your PDB over a database link. The database link needs to be created in the target CDB, which is the test environment on Amazon RDS Custom for Oracle in this use case. The database link will connect to the source in the production environment where we want to clone from.
The following are a few criteria related to database character sets, open mode of the source DB, and the database link required to perform a remote clone:
- The source PDB must not be closed.
- If the remote CDB is not in local undo mode, then the source PDB must be open in read-only mode.
- If the remote CDB is not in ARCHIVELOG mode, then the source PDB must be open in read-only mode.
- A database link must enable a connection from the destination CDB (the CDB to which the PDB is being cloned) to the PDB in the source CDB.
- The database link can connect as a common user to the root of the source CDB, or as a common or local user to the source PDB. The source PDB can be either a standard PDB or application PDB.
For more details about the prerequisites, refer to Cloning a Remote PDB: Basic Steps.
Connect to the EC2 instance of the RDS Custom for Oracle target instance and perform the following steps:
- Add the details of the source database in the
In the preceding code, CLONE_SRC is the identifier in
tnsnames.ora for the source database instance.
- Log in to the target database and create a database link called
- Use the database link to clone the
ORCL_CL3PDB from source to
Best practices for PDB resource management
Oracle Multitenant is a database architecture that allows multiple pluggable databases (PDBs) to share a single container database (CDB), providing a more efficient and consolidated approach to database management. Proper resource management is critical for maintaining the performance and stability of a multitenant environment.
In this context, best practices for Oracle multitenant PDB resource management refer to the guidelines and strategies that organizations can follow to optimize the allocation and utilization of system resources, such as CPU, memory, and disk space, across the CDB and its PDBs.
In this section, we share some of the best practices for managing resource allocation to PDBs.
You can set the following parameters at the PDB level to control the minimum or maximum SGA allocation to each PDB, depending on your workload requirements:
- SGA_TARGET – Maximum SGA size for a PDB.
- SGA_MIN_SIZE – Minimum SGA size for the PDB. This parameter is only applicable for PDBs.
As per About memory configuration parameter on each PDBs (Doc ID 2655314.1), do not set
db_cache_size at PDB level. Instead, let the instance manage it automatically using
I/O rate (IOPS and throughput) limit
You can set the following parameters at the PDB level to limit I/O usage by PDBs. The default values for these parameters is zero (there are no limits). If these parameters are set at CDB$ROOT level, all PDBs will inherit those limits. Use the following parameters to limit the I/O rate for individual PDBs as per your requirements:
- MAX_IOPS – Maximum number of I/O that can be issued per second on a per PDB basis
MAX_MBPS – Maximum number of megabytes of I/O issued per second on a per PDB basis
If a certain process is rate limited due to these parameters, then the wait event is
resmgr:I/O rate limit.
For more details, refer to I/O Rate Limits for PDBs 12.2 New feature (Doc ID 2164827.1).
You can use
V$RSRCPDBMETRIC, V$RSRCPDBMETRIC_HISTORY, and
DBA_HIST_RSRC_PDB_METRIC to check usage of IOPS and IOMBPS usage by a certain PDB. You can use the same information to set upper limits.
For example, use the following code to calculate the maximum usage of these metrics for a certain period:
Use performance profiles for OS resource allocation
If you have more than one user-created PDB in the CDB, consider using Oracle Resource Manager for these PDBs to allocate resources. Resource Manager can be enabled at two levels:
- CDB level – At this level, you allocate resources for each PDB and limit utilization of specific PDBs using a CDB resource plan
- PDB level – Within a PDB, if you want to limit resource utilization by certain workloads, use a PDB-level resource plan
For more information about using performance profiles for easier OS resource allocation management of several PDBs, refer to Managing OS Resources Among PDBs Using PDB Performance Profiles – 12.2 New Feature (Doc ID 2171135.1).
Monitoring best practices
Monitoring is an important part of maintaining the reliability, availability, and performance of Amazon RDS Custom for Oracle. If you’re familiar with Amazon RDS for Oracle, you can understand the capability of CloudWatch in terms of monitoring. For a solution using CloudWatch with an RDS Custom for Oracle environment, refer to Monitor Amazon RDS Custom for Oracle with Amazon CloudWatch metrics. You can extend this solution to monitor self-managed Oracle installations on Amazon EC2. This will enable you to monitor the health of Oracle instances (both Amazon RDS Custom and self-managed) and observe changes to the infrastructure and databases workloads. You can monitor metrics over a specific time period and set CloudWatch alarms to receive notifications.
In this post, we provided step-by-step guidance on the operational best practices for using Amazon RDS Custom for Oracle Multitenant. We discussed efficient management of an RDS Custom for Oracle container database using resource management, local undo, and HugePages. We also discussed a monitoring solution so that performance and infrastructure issues can be addressed in a timely manner.
We welcome your feedback. If you have questions or suggestions, leave them in the comments section.
About the authors
Arnab Saha is a Senior Database Specialist Solutions Architect at AWS. Arnab specializes in Amazon RDS, Amazon Aurora and Amazon Elastic Block Store. He provides guidance and technical assistance to customers thus enabling them to build scalable, highly available and secure solutions in AWS Cloud.
Vishal Patil is a Senior Database Specialist Solutions Architect with Amazon Web Services. He is a part of AWS RDS team, which focuses on managed services that makes it simple to set up, operate, and scale databases in the cloud. He enjoys listening to customer requirements and helps them migrate and optimally run Oracle workloads in AWS.