The document compares different consolidation methods for Oracle databases including virtualization, containers, multi-instance, schema consolidation, and Oracle Multitenant. It lists pros and cons for each method related to overhead, OS separation, patching, high availability functionality, and licensing/support considerations.
Download as DOCX, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
17 views
Oracle Database Consolidation Comparison
The document compares different consolidation methods for Oracle databases including virtualization, containers, multi-instance, schema consolidation, and Oracle Multitenant. It lists pros and cons for each method related to overhead, OS separation, patching, high availability functionality, and licensing/support considerations.
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4
Consolidation Method PROS CONS
Virtualization - Complete OS separation. - Overhead associated with
- Allows differing OS versions in running the hypervisor on each machine. the hardware. - Allows differing DB versions in - Overhead associated with each machine. running an entire OS in - Allows separation of duties if each VM. different teams need to control - Each OS has to be patched each VM. and monitored separately. - The virtual infrastructure can be - Overhead of multiple DBs used to provide basic high running on a single availability (HA) functionality. physical server. - Each DB has to be patched and monitored separately. - Someone needs to take on the responsibility of learning about and maintaining the virtualization infrastructure. - Licensing and support of the virtualization infrastructure. Containers - Reduced overhead as only one - Containers do not provide OS is running on the physical complete OS separation. hardware. Depending on - Reduced OS patching as the OS configuration, you may get is shared between all the bleed-over effects, where containers. one container can - Some separation, making each adversely affect the container "feel" like a separate performance of another. installation. - The lack of complete OS - With a separate Oracle separation means there installation in each container, may be security each database could run at a implications where different database version if containers are concerned. required. - Operating system patches - The container functionality can affect all containers. be used to provide basic high - Someone needs to take on availability (HA) functionality. the responsibility of learning about and maintaining the container infrastructure. - Overhead of multiple DBs running on a single physical server. - Each DB has to be patched and monitored separately. - Licensing and support of the container feature. Not all container solutions are supported to run Oracle products. Multi-Instance - Reduced overhead as only one - No OS separation. OS is running. - The lack of complete OS - Reduced OS patching as the OS separation means there is shared between all the may be security containers. implications if you make - Can share a single Oracle silly mistakes. installation, or have a separate - Operating system patches Oracle installation per database, affect all instances. allowing each database to run at - Overhead of multiple DBs a different database version if running on a single required. physical server. - No additional cost or knowledge - If you are using multiple needed to support a containers Oracle installations, they or virtualization. will all have to be patched - Depending on the setup, separately. If you are using patching and monitoring may be a shared installation, all simplified. At a minimum, we databases must be kept at may only need a single Oracle the same version. installation and a single Cloud - Does not provide any High Control agent on the server. Availability (HA) functionality directly, but Data Guard and Real Application Clusters (RAC) can provide this at an extra cost. Schema Consolidation - Reduced overhead as only one - No OS separation, making OS is running. it harder to prioritize - Reduced overhead as only one performance of specific DB instance is running. schemas. Resource - Only a single database Manager cannot control installation is present. memory usage. - No additional cost and - The lack of complete OS knowledge needed to support a separation means there containers or virtualization. may be security - Depending on the setup, implications if you make patching and monitoring may be silly mistakes. simplified. At a minimum, we - Operating system patches may only need a single Oracle affect all applications. installation and a single Cloud - Database patches affect all Control agent on the server. applications. - Instance level changes affect all applications. - Does not provide any High Availability (HA) functionality directly, but Data Guard and Real Application Clusters (RAC) can provide this at an extra cost. - Database recovery and flashback have to be planned carefully as all top-level operations affect all schemas. This can be mitigated using tablespace point in time recovery (PITR). Oracle Multitenant - Reduced overhead as only one - The multitenant option is a OS is running. chargeable Enterprise - Reduced overhead as only one Edition option. DB instance is running. - No OS separation, making - Only a single database it harder to prioritize installation is present. performance of specific - No additional cost or knowledge pluggable databases. needed to support a containers Resource Manager cannot or virtualization. control memory usage. - Depending on the setup, - The lack of complete OS patching and monitoring may be separation means there simplified. At a minimum, we may be security may only need a single Oracle implications if you make installation and a single Cloud silly mistakes. Control agent on the server. - Operating system patches - Namespace separation, allowing affect all applications. you to have public database - Database patches affect all links, synonyms and even the applications. This can be same usernames in each PDB. mitigated by using the unplug/plugin approach to patches and upgrades, as described here. - Instance level changes affect all applications. Some initialization parameters are PDB- specific, as described here. - Does not provide any High Availability (HA) functionality directly, but Data Guard and Real Application Clusters (RAC) can provide this at an extra cost. - Database recovery and flashback have to be planned carefully as all top-level operations affect all pluggable databases. This can be mitigated using PDB point in time recovery (PITR).
Attract Women Unlock Her Legs How To Effortlessly Attract Women and Become The Man Women Unlock Their Legs For (Dating Advice... (Dominic Mann) (Z-Library)