Moving virtual machine (vm) database (db) systems from one compartment to another

Oracle has built database technologies, business applications, and infrastructure that enterprises have valued for over 40 years. Oracle Cloud consists of both the infrastructure (server + storage) and the platform that serves as a database on top of the core infrastructure. The value of moving your on premise database to the Cloud; however, extends beyond no longer having to do infrastructure management.

Nội dung chính Show

Overview of Oracle Database Cloud Service
Management of Bare Metal and VM DB Systems
Monitoring a Database:
Which statement is true about moving virtual machine VM database DB systems from one compartment to another?
Can resources be moved from one compartment to another?
What are two typical reasons why customers Cannot move their database into the public cloud?
Which 2 locations can be used to store your DB system database backups?

Oracle Cloud Infrastructure (OCI) provides you with the ability to deploy Oracle databases in the Cloud, with Oracle providing the physical storage, computing power, and tooling (e.g. backup, recovery, patching, upgrade operations) for routine database maintenance. Customers using Classic Cloud Service have full administrative privileges for the created Oracle database. At a high-level, Database Cloud Service offers:

Lowered costs: After moving your on premise database to the Cloud, you will no longer need to rely on a database administrator expert. By reducing such variable costs, your company can focus on business needs that really matter.
Disaster Recovery: Oracle Database Management offerings in the Cloud automatically backs up your data in the unfortunate event that you may need to recover it.
- Oracle Cloud Infrastructure offers you the ability to create and store automatic daily backups and on-demand full backups. You can store backups in your DB system's local storage, or in Oracle Cloud Infrastructure Object Storage. Automatic Incremental and Archived Redo Log Backups
  When you enable the Automatic Backup feature for a database, the service creates the following on an on-going basis:
- Weekly level 0 backup, generally created on a specified weekend day. A level 0 backup is the equivalent of a full backup. Note that in the Console, weekly level 0 backups appear in the list of backups with backup type "incremental", as do the daily level 1 backups.
- Daily level 1 backups, which are incremental backups created on each day for the six days following the level 0 backup day.
- Level 0 and level 1 backups are stored in Object Storage and have an assigned OCID .
- Ongoing archived redo log backups (with a minimum frequency of every 60 minutes). The Last Backup Time field on the database details page in the Oracle Cloud Infrastructure Console displays the time of the last archived redo logs. This backup differs from the level 0 and level 1 automatic backups in that it is based on log data and does not have an assigned OCID . The last archived redo log backup can be used to create a new database or to recover a database with minimal data loss.
- Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. The Oracle Cloud Infrastructure Database Data Guard implementation requires two databases: one in a primary role and one in a standby role. The two databases make an Oracle Data Guard association. Most of your applications access the primary database, while the standby database is a transactionally consistent copy of the primary database.
- Oracle Data Guard maintains the standby database by transmitting and applying redo data from the primary database. If the primary database becomes unavailable, then you can use Oracle Data Guard to switch or fail over the standby database to the primary role.

Switchover

A switchover reverses the primary and standby database roles. Each database continues to participate in the Oracle Data Guard association in its new role. A switchover ensures no data loss. Performing planned maintenance on a DB system with an Oracle Data Guard association is typically done by switching the primary database to the standby role, performing maintenance on the standby database, and then switching it back to the primary role.

Failover

A failover transitions the standby database into the primary role after the existing primary database fails or becomes unreachable. A failover might result in some data loss when you use Maximum Performance protection mode.

Reinstate

Reinstates a database into the standby role in an Oracle Data Guard association. You can use the reinstate command to return a failed database into service after correcting the cause of failure.

Scalability
Two-node Oracle RAC DB systems require Oracle Enterprise Edition - Extreme Performance.
- When you launch a virtual machine DB system, you choose a shape, which determines the resources allocated to the DB system. After you provision the system, you can change the shape to adapt to new processing capacity requirements.
Security: Oracle Cloud Infrastructure is a Infrastructure-as-a-Service (Iaas) that embeds security-first architecture design principles, including isolated network virtualization which aims to prevent lateral movement and zero trust architecture with malware free hosts built in. Oracle Cloud Infrastructure also offers a number of security controls to customers in both its physical hardware located at data centers and its web layer. Among these tiered defenses are: data encryption, identity protection, CASB, web application firewalls, and cloud guard. These protections also work with third-party clouds and on-premise solutions to help secure modern enterprise workloads.
Performance: Oracle Application Performance Monitoring Cloud Services empowers customers with the information they need to find and fix application issues swiftly. End-user and application performance information (including associated application logs) are synthesized into a unified data set. With Cloud services, you can set alert thresholds for defined metrics in the Infrastructure Classic Console, including monitoring real-time service usage data to determine how best to allocate resources.
- ExaCS services: A scalable architecture offloads SQL queries and analytics to storage servers, allowing customers to run all types of Oracle Database workloads faster on Exadata Cloud Service. SQL read latency as low as 19 microseconds, 50X faster than the 1 millisecond latency of AWS Relational Database (RDS), enables customers to run database workloads faster, consume fewer resources, and lower costs.
- DbaaS on Bare Metal infrastructure: Bare-metal infrastructure allows customers to optimize Oracle Enterprise Database Service performance using dedicated hardware with low-latency NVMe storage. Isolated database service resources allow customers to maximize security and achieve high levels of predictable performance.
  - Dedicated servers with 52 CPU cores and 768 GB of memory enable customers to run databases with high performance
  - Built-in NVME storage optimizes performance for latency-sensitive customer databases with a choice of 16 TB of usable capacity with 2-way mirroring or 9 TB of capacity with 3-way mirroring
  - On-demand up and down scaling of database OCPUs without interrupting database operations allows customers to meet application needs while minimizing costs
- Enterprise Edition Extreme Performance: allows customers to optimize resources, utilization, availability, and performance for enterprise environments. Available on virtual machine and bare metal infrastructure.
  - Adds advanced availability and performance technologies to Enterprise Database Service High Performance subscription
  - Enterprise database storage provisioning with Oracle Automatic Storage Management mirroring in virtual machine environments increases the availability of customer databases
  - Additional high-availability capabilities, including Oracle Real Application Clusters (Oracle RAC) support in virtual machine environments and Oracle Active Data Guard, enable customers to deploy resilient environments across multiple systems, availability domains, or Oracle Cloud Infrastructure regions
  - Additional performance capabilities, such as support for Oracle In-memory column stores and aggregation, allow customers to increase performance for data warehouses and analytics
  - Additional Oracle Sharding capabilities supporting unlimited primary and standby shards for increased performance and deployment flexibility

Overview of Oracle Database Cloud Service

The Database service offers autonomous and co-managed Oracle Database cloud solutions.

Autonomous databases are preconfigured, fully-managed environments that are suitable for either transaction processing or for data warehouse workloads.
Co-managed solutions are bare metal, virtual machines and Exadata DB systems that you can customize with the resources and settings that meet your needs.

You can quickly provision an autonomous database or co-manage DB system. As a customer, you have full access to the features and operations available with the database, but Oracle owns and manages the infrastructure.

Autonomous Databases

The Database service offers Oracle's Autonomous Database with transaction processing and data warehouse workload types.

Co-Managed Systems

Exadata Cloud@Customer

Management of Bare Metal and VM DB Systems

Below are some of the Management tasks that can be performed with ease on the OCI Console -

Starting, stopping, rebooting, and terminating a DB system
Scaling the CPU count and storage
Changing the shape of a virtual machine DB system
Managing (NSGs) for your system
Managing licenses for your DB system
Checking the system status
Moving a system to another compartment
Creating a serial console connection to your DB system nodes
Managing for your system
Viewing related to your system

Navigate to Bare Metal VM ExaData → Select the Compartment → Select the DB System.

The below Console screen can be used to perform Management tasks like Starting , Stopping, Rebooting, Scaling Storage, Changing Shape , Terminating the instance, Updating License Type, Adding Tags, and Moving the Resources.

The below Console screen is used for Patching the DB System and the Database. You would run the Pre-Check and then Apply to get to the latest Patch release.

Below console page would be used to change the License Type.

Navigate to Bare Metal VM ExaData → Select the Compartment → Select the DB System→ Click More Actions → Clic Update License Type

Monitoring a Database:

Enterprise Manager Express console is used to monitor a version 12.1.0.2 or later database

On 1- and 2-node RAC DB Systems, by default, the EM Express console is not enabled on version 18.1.0.0, 12.2.0.1, and 12.1.0.2 databases. You can enable it for an existing database or you can enable it when you create a database by using the command with the -co parameter.You must also update the security list and iptables for the DB system.

Below is the Console Page for EM Express :

Below are some of the Alerts metrics that can be monitored and the thresholds setup page ..

From the target home page: Oracle Database menu > Monitoring > All metrics

The below screenshots displays the Incident Rules and corresponding Notification setup for an alert.

OCI Cloud Native Monitoring Services:

Oracle Cloud Infrastructure Monitoring helps optimize the resource utilization and uptime of the infrastructure and applications.

Conclusion

Thus we see how the management of the database system is relatively easy in Database Cloud Service compared to On Premise. Most of the mundane tasks are carried out with a click of a button on the Console. Additionally, DCS can reduce overhead and operational costs, investments in hardware and associated maintenance, and large workloads at scale without a jump in pricing. It also provides greater scalability enabling you to provide as much (or as little) compute power and storage as your workload demands.

To learn more about our Oracle Cloud solutions click here or schedule a meeting with a Database Cloud Service expert.

Which statement is true about moving virtual machine VM database DB systems from one compartment to another?

Which statement is true about moving virtual machine (VM) database (DB) systems from one compartment to another? You can move DB systems to a different compartment if you have sufficient access permissions to the compartment that the resource is being moved to as well as the current compartment.

Can resources be moved from one compartment to another?

Moving Resources to a Different Compartment Most resources can be moved after they are created. There are a few resources that you can't move from one compartment to another.

What are two typical reasons why customers Cannot move their database into the public cloud?

There are also cases where customers cannot move data to a public cloud due to data sovereignty/data residency, legal, or business policy requirements—and, as such, keeping data within their datacenters and/or a local public cloud region is a must.