Wednesday, 24 November 2021

Backing Up a Container Database to Oracle Cloud Infrastructure Object Storage

  Note


This topic is not applicable to Exadata DB systems. For Exadata DB systems, see Managing Exadata Database Backups.

This topic explains how to work with backups managed by Oracle Cloud Infrastructure. You do this by using the Console or the API. (For unmanaged backups, you can use RMAN or dbcli, and you must create and manage your own Object Storage buckets for backups. See Backing Up a Container Database to Object Storage Using RMAN.)

 Caution

If you previously used RMAN or dbcli to configure backups and then you switch to using the Console or the API for backups, a new backup configuration is created and associated with your database. This means that you can no longer rely on your previously configured unmanaged backups to work.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

If you're new to policies, see Getting Started with Policies and Common Policies.

Prerequisites

The DB system requires access to the Oracle Cloud Infrastructure Object Storage service, including connectivity to the applicable Swift endpoint for Object Storage. Oracle recommends using a service gateway with the VCN to enable this access. For more information, see these topics:

 Important

Note that your database and DB system must be in an “Available” state for a backup operation to run successfully. Oracle recommends that you avoid performing actions that could interfere with availability (such as patching and Data Guard operations) while a backup operation is in progress. If an automatic backup operation fails, the Database service retries the operation during the next day’s backup window. If an on-demand full backup fails, you can try the operation again when the DB system and database availability are restored.

In addition to the prerequisites listed, ensure that the following conditions are met to avoid backup failures:

  • The database's archiving mode is set to ARCHIVELOG (the default).
  • The /u01 directory on the database host file system has sufficient free space for the execution of backup processes.
  • The .bash_profile file for the oracle user does not include any interactive commands (such as oraenv or one that could generate an error or warning message).
  • (For automatic backups) No changes were made to the default WALLET_LOCATION entry in the sqlnet.ora file.
  • No changes were made to RMAN backup settings by using standard RMAN commands.

See Backup Failures on Bare Metal and Virtual Machine DB Systems for details on problems that can result from not following these guidelines.

Oracle Cloud Infrastructure Managed Backup Features

The following information applies to managed backups configured using the Oracle Cloud Infrastructure Console or API.

 Note

Databases in a security zone compartment must have automatic backups enabled. See the Security Zone Policies topic for a full list of policies that affect Database service resources.

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.

The automatic backup process used to create level 0 and level 1 backups can run at any time within the daily backup window (between midnight and 6:00 AM). See note for backup window time zone information. Automatic incremental backups (level 0 and level 1) are retained in Object Storage for 30 days by default.

Backup Retention

If you choose to enable automatic backups, you can choose one of the following preset retention periods: 7 days, 15 days, 30 days, 45 days, or 60 days. The system automatically deletes your incremental backups at the end of your chosen retention period.

Audit and Trace File Retention for Databases Using Automatic Backups

Oracle Database writes audit and trace files to your database's local storage in the /u01 directory. These files are retained for 30 days by default, though you can change this interval. Once a day, audit and trace files older than 30 days (or the user-specified interval, if applicable) are discarded by a Oracle Scheduler job. You can also disable the Scheduler job if you want to retain these files permanently. Use the following dbcli commands to make changes to this Scheduler job.

  • To change the retention period from the default setting of 30 days:

    dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>

    For example:

    dbcli update-database -in inventorydb -lr 15

  • To disable the daily discard Scheduler job for older audit and trace files:

    dbcli update-schedule -i <schedulerID> -d

    For example:

    dbcli update-schedule -i 5678 -d

Backup Scheduling

The automatic backup process starts at any time during your daily backup window. You can optionally specify a 2-hour scheduling window for your database during which the automatic backup process will begin. There are 12 scheduling windows to choose from, each starting on an even-numbered hour (for example, one window runs from 4:00-6:00 AM, and the next from 6:00-8:00 AM). Backups jobs do not necessarily complete within the scheduling window

The default backup window of 00:00 to 06:00 in the time zone of the DB system's region is assigned to your database if you do not specify a window. Note that the default backup scheduling window is six hours long, while the windows you specify are two hours long. See note for backup window time zone information.

 Note

  • Backup Window Time Zone - Automatic backups enabled for the first time after November 20, 2018 on any database will run between midnight and 6:00 AM in the time zone of the DB system's region. If you have enabled automatic backups on a database before this date, the backup window for the database will continue to be between midnight and 6:00 AM UTC. You can create a My Oracle Support service request to have your automatic backups run in a backup window of your choice.
  • Data Guard - You can enable the Automatic Backup feature on a database with the standby role in a Data Guard association. However, automatic backups for that database will not be created until it assumes the primary role.
  • Retention Period Changes - If you shorten your database's automatic backup retention period in the future, existing backups falling outside the updated retention period are deleted by the system.
  • Object Storage Costs - Automatic backups incur Object Storage usage costs.

On-Demand Full Backups

You can create a full backup of your database at any time unless your database is assuming the standby role in a Data Guard association.

Standalone Backups

When you terminate a DB system or a database, all of its resources are deleted, along with any automatic backups. Full backups remain in Object Storage as standalone backups. You can use a standalone backup to create a new database.

Using the Console

You can use the Console to enable automatic incremental backups, create full backups on demand, and view the list of managed backups for a database. The Console also allows you to delete full backups.

 Note

The list of backups you see in the Console does not include any unmanaged backups (backups created directly by using RMAN or dbcli).

All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.

on No comments:

Managing Bare Metal and Virtual Machine DB Systems in OCI

 

Managing Bare Metal and Virtual Machine DB Systems

This topic explains how to perform a variety of management tasks for a bare metal or virtual machine database system. Tasks include:

  • Starting, stopping, rebooting, and terminating a DB system
  • Scaling the CPU count and storage
  • Changing the shape of a virtual machine DB system
  • Managing network security groups (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 tags for your system
  • Viewing work requests related to your system

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

For administrators: The policy in Let database admins manage Oracle Cloud database systems lets the specified group do everything with databases and related Database resources.

If you're new to policies, see Getting Started with Policies and Common Policies. If you want to dig deeper into writing policies for databases, see Details for the Database Service.

Using the Console

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage DB system components.

database systems:

Database homes:

Databases:

Nodes:

For the complete list of APIs for the Database service, see Database Service API.

on No comments:

Sunday, 21 November 2021

Network Setup for Exadata Cloud Service Instances

 


Before you set up an Exadata Cloud Service instance, you must set up a virtual cloud network (VCN) and other Networking service components. This topic describes the recommended configuration for the VCN and several related requirements for the Exadata Cloud Service instance.

VCN and Subnets

To launch an Exadata Cloud Service instance, you must have:

  • A VCN in the region where you want the Exadata Cloud Service instance

  • At least two subnets in the VCN. The two subnets are:

    • Client subnet
    • Backup subnet
 Note

For Exadata Cloud Service instances using the new Exadata resource model, networking is configured on the cloud VM cluster resource. For instances using DB system resource model, networking is configured on the DB system resource.

In general, Oracle recommends using regional subnets , which span all availability domains  in the region. If you instead use AD-specific subnets , both the client and backup subnets must be in the same availability domain. The important thing to know for your Exadata Cloud Service instance is that the resources you create in the two subnets must be in the same availability domain. For more information, see Overview of VCNs and Subnets.

You will create custom route tables  for each subnet. You will also create security rules  to control traffic to and from the client network and backup network of the Exadata compute notes (for cloud VM clusters, nodes are called virtual machines). More information follows about those items.

Option 1: Public Client Subnet with Internet Gateway

This option can be useful when doing a proof-of-concept or development work. You can use this setup in production if you want to use an internet gateway  with the VCN, or if you have services that run only on a public network and need access to the database. See the following diagram and description.

This image shows the network setup with a public client subnet.

You set up:

 Important

See this known issue for information about configuring route rules with service gateway as the target on route tables associated with public subnets.

Option 2: Private Subnets

Oracle recommends this option for a production system. Both subnets are private and cannot be reached from the internet. See the following diagram and description.

This image shows the network setup with a private client subnet.

You set up:

Requirements for IP Address Space

If you're setting up Exadata Cloud Service instances (and thus VCNs) in more than one region, make sure the IP address space of the VCNs does not overlap. This is important if you want to set up disaster recovery with Oracle Data Guard.

The two subnets you create for the Exadata Cloud Service instance must not overlap with 192.168.128.0/20.

The following table lists the minimum required subnet sizes, depending on the Exadata rack size. For the client subnet, each node requires three IP addresses, and in addition, three addresses are reserved for Single Client Access Names (SCANs). For the backup subnet, each node requires two addresses.

 Tip

The Networking service reserves three IP addresses in each subnet. Allocating a larger space for the subnet than the minimum required (for example, at least /25 instead of /28) can reduce the relative impact of those reserved addresses on the subnet's available space.
Rack SizeClient Subnet: # Required IP AddressesClient Subnet: Minimum SizeBackup Subnet: # Required IP AddressesBackup Subnet: Minimum Size
Base System or Quarter Rack

(3 addresses * 2 nodes) + 3 for SCANs + 3 reserved in subnet = 12

 		/28 (16 IP addresses)(2 address * 2 nodes) + 3 reserved in subnet = 7/29 (8 IP addresses)
Half Rack(3 * 4 nodes) + 3 + 3 = 18/27 (32 IP addresses)(2 * 4 nodes) + 3 = 11/28 (16 IP addresses)
Full Rack(3* 8 nodes) + 3 + 3 = 30/27 (32 IP addresses)(2 * 8 nodes) + 3 = 19/27 (32 IP addresses)
Flexible infrastructure systems (X8M and higher)3 addresses per database node (minimum of 2 nodes) + 3 for SCANs + 3 reserved in subnetMinimum size determined by total number of IP addresses needed for database nodes2 address per database node (minimum of 2 nodes) + 3 reserved in subnetMinimum size determined by total number of IP addresses needed for database nodes

VCN Creation Wizard: Not for Production

The Networking section of the Console includes a handy wizard that creates a VCN along with related resources. It can be useful if you just want to try launching an instance. However, the wizard automatically creates a public subnet and an internet gateway. You may not want this for your production network, so Oracle recommends you create the VCN and other resources individually yourself instead of using the wizard.

DNS: Short Names for the VCN, Subnets, and Exadata Cloud Service instance

For the nodes to communicate, the VCN must use the Internet and VCN Resolver. It enables hostname assignment to the nodes, and DNS resolution of those hostnames by resources in the VCN. It enables round robin resolution of the database's SCANs. It also enables resolution of important service endpoints required for backing up databases, patching, and updating the cloud tooling on an Exadata Cloud Service instance. The Internet and VCN Resolver is the VCN's default choice for DNS in the VCN. For more information, see DNS in Your Virtual Cloud Network and also DHCP Options.

When you create the VCN, subnets, and Exadata, you must carefully set the following identifiers, which are related to DNS in the VCN:

  • VCN domain label
  • Subnet domain label
  • Hostname prefix for the Exadata Cloud Service instance's cloud VM cluster or DB system resource

These values make up the node's fully qualified domain name (FQDN):

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

For example:

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

In this example, you assign exacs as the hostname prefix when you create the cloud VM cluster or DB system. The Database service automatically appends a hyphen and a five-letter string with the node number at the end. For example:

  • Node 1: exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • Node 2: exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • Node 3: exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • And so on

Requirements for the hostname prefix:

  • Recommended maximum: 12 characters. For more information, see the example under the following section, "Requirements for the VCN and subnet domain labels".
  • Cannot be the string localhost

Requirements for the VCN and subnet domain labels:

  • Recommended maximum: 14 characters each. The actual underlying requirement is a total of 28 characters across both domain labels (excluding the period between the labels). For example, both of these are acceptable: subnetad1.verylongvcnphx or verylongsubnetad1.vcnphx. For simplicity, the recommendation is 14 characters each.
  • No hyphens or underscores.

  • Recommended: include the region name in the VCN's domain label, and include the availability domain name in the subnet's domain label.

  • In general, the FQDN has a maximum total limit of 63 characters. Here is a safe general rule:

    <12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

The preceding maximums are not enforced when you create the VCN and subnets. However, if the labels exceed the maximum, the Exadata deployment fails.

DNS: Between On-Premises Network and VCN

Oracle recommends using a private DNS resolver to enable the use of hostnames when on-premises hosts and VCN resources communicate with each other. See Private DNS resolvers for information on creating and using private resolvers. For a reference architecture see Use private DNS in your VCN in the Oracle Architecture Center.

Node Access to Object Storage: Static Route

To be able to back up databases, and patch and update cloud tools on an Exadata Cloud Service instance, you must configure access to Oracle Cloud Infrastructure Object Storage. Regardless of how you configure the VCN with that access (for example, with a service gateway), you may also need to configure a static route to Object Storage on each of the compute nodes in the cluster. This is only required if you are not using automatic backups. If you are using customized backups using the backup APIs, then you must route traffic destined for Object Storage through the backup interface (BONDETH1). This is not necessary if you are using the automatic backups created with the Console, APIs, or CLIs.

 Important

You must configure a static route for Object Storage access on each compute node in an Exadata Cloud Service instance if you are not creating automatic backups with the Console, APIs, or CLIs. Otherwise, attempts to back up databases, and patch or update tools on the system, can fail.

Security Rules for the Exadata Cloud Service instance

This section lists the security rules to use with your Exadata Cloud Service instance. Security rules control the types of traffic allowed for the client network and backup network of the Exadata's compute nodes. The rules are divided into three sections.

There are different ways to implement these rules. For more information, see Ways to Implement the Security Rules.

 Note

For X8M systems, Oracle recommends that all ports on the client subnet need to be open for ingress and egress traffic. This is a requirement for adding additional database servers to the system.

Rules Required for Both the Client Network and Backup Network

This section has several general rules that enable essential connectivity for hosts in the VCN.

If you use security lists to implement your security rules, be aware that the rules that follow are included by default in the default security list. Update or replace the list to meet your particular security needs. The two ICMP rules (general ingress rules 2 and 3) are required for proper functioning of network traffic within the Oracle Cloud Infrastructure environment. Adjust the general ingress rule 1 (the SSH rule) and the general egress rule 1 to allow traffic only to and from hosts that require communication with resources in your VCN.

 Note

General ingress rule 1: Allows SSH traffic from anywhere
General ingress rule 2: Allows Path MTU Discovery fragmentation messages
General ingress rule 3: Allows connectivity error messages within the VCN
General egress rule 1: Allows all egress traffic

Rules Required Specifically for the Client Network

The following security rules are important for the client network.

 Important

  • For X8M systems, Oracle recommends that all ports on the client subnet need to be open for ingress and egress traffic. This is a requirement for adding additional database servers to the system.
  • Client ingress rules 1 and 2 only cover connections initiated from within the client subnet. If you have a client that resides outside the VCN, Oracle recommends setting up two additional similar rules that instead have the Source CIDR set to the public IP address of the client.
  • Client ingress rules 3 and 4 and client egress rules 1 and 2 allow TCP and ICMP traffic inside the client network and enable the nodes to communicate with each other. If TCP connectivity fails across the nodes, the Exadata cloud VM cluster or DB system resource fails to provision.
Client ingress rule 1: Allows ONS and FAN traffic from within the client subnet
Client ingress rule 2: Allows SQL*NET traffic from within the client subnet
Client egress rule 1: Allows all TCP traffic inside the client subnet
Client egress rule 2: Allows all egress traffic (allows connections to the Oracle YUM repos)

Rule Required Specifically for the Backup Network

The following security rule is important for the backup network because it enables the DB system to communicate with Object Storage through the service gateway (and optionally with the Oracle YUM repos if the client network doesn't have access to them). It is redundant with the general egress rule in Security Rules for the Exadata Cloud Service instance (and in the default security list). It is optional but recommended in case the general egress rule (or default security list) is inadvertently changed.

Backup egress rule: Allows access to Object Storage
on No comments:
Subscribe to: Posts (Atom)