Posted in: Cloud, Oracle, Technical Track
I recently published a blog post about large pages support in AWS RDS for Oracle and someone asked me if and how it works on Oracle cloud. I didn’t actually know the answer and decided to look it up. Documentation for Oracle Cloud didn’t say much about HugePages or large pages support for Oracle Cloud Database Service. I only found directions for Oracle Database Exadata Cloud Service in the documentation. The most reliable way, of course, was to go and check and that’s what I did. Please keep in mind that the information in this post may become obsolete since Oracle Cloud is constantly undergoing changes.
In this blog post I will focus on setting up backups from on-premise to the Oracle Cloud using the Oracle Database Backup Service. I do encourage you to test this; you can get a free 30-day trial account on the Oracle Cloud to play with these options. When using the Oracle Database Backup Service, RMAN will be used excellent!
Oracle has two types of Oracle Cloud platforms where one is called “Classic” and another is called “Oracle Cloud Infrastructure” or “OCI”. I started my tests with the latter. In the OCI interface I created a DB system (VM based) with “VM.Standard1.1” shape which comes with 1 OCPU and 7 GB of memory.
As soon as the VM was successfully deployed I started to check the system. To my surprise I found that the HugePages were not configured. On the OS level we saw 0 defined large pages in the memory:
And the database instance parameter “use_large_pages” was explicitly setup to false:
The large pages were not set up out of the box with the provisioned service as I was expecting. On the Oracle Cloud, we possessed full control on OS level for our VM. What if we tried to enable the HugePages for the database? The database was not using AMM and was configured for ASMM instead which was fully aligned with using large pages for SGA.
Also I noticed that the users limits for Oracle were already configured to support up to almost 5Tb of locked memory.
It seemed like the system was almost ready and we should just enable HugePages on OS level, switch the use_large_pages parameter to “TRUE” or “ONLY” and bounce the instance. It was exactly what I did.
I changed the database instance parameter:
I changed the database instance parameter:
Stopped the instance using srvctl:
Modified the hugepages.
And started the database back:
After that I could see that the memory in large pages had been used and the instance alert log clearly stated that 897 large pages out of 900 were allocated by the database.
Everything worked out fine and I got the database with SGA running in HugePages memory. I didn’t see any errors or problems while doing some small tests on the database. Everything worked correctly. I tried with a couple of different shapes for the VM and got the similar results. It appeared that on the OCI platform the HugePages were not used for database systems based on VM by default. I didn’t try all types of VM but the configuration and behaviour looked the same for the other shapes only SGA and PGA parameters were growing along with new size of the instances. For example, on the “VM.Standard1.2” we were getting more memory on the box, bigger SGA but the large pages were not used anyway.
The next step was to check the Oracle “Classic” cloud database service. It had different definition for the standard configurations and I started from “OC4” with 2 OCPU and 15 GB memory. The instance was created and I could see that it was using HugePages out of box. It was exactly what I expected from the Oracle Cloud.
The database instance parameter “use_large_pages” was setup to “TRUE”
The database instance parameter “use_large_pages” was setup to “TRUE”
And the instance alert log showed clearly that 2649 large pages out of configured 2916 were used allocated.
Here is a short summary. Oracle database service on OCI gives you VM and database instance without large pages configuration when the database service on “Classic” cloud platform provides you a VM and an instance with large pages setup. I was not able to find any recommendation or notes in the documentation for Oracle Cloud regarding large page usage for database service on “OCI” cloud. I was surprised that it was not configured out of the box there. From my point of view, it definitely makes sense to use large pages if a system supports it. So, if you still don’t use it, you may try to test it on OCI and maybe double verify with Oracle support before going to production.
Interested in working with Gleb? Schedule a tech call.
Posted in: Cloud, Oracle, Technical Track
This is part 1 of 3 in a series on “Getting Started with Oracle Cloud Backups”.
- Part 1 covers setting up RMAN to backup directly to the new Oracle Cloud Database Backup Service (ODBS) (part of the Oracle Public Cloud or OPC).
- Part 2 covers setting up RMAN to backup directly to the cloud using Amazon Web Services (AWS) Simple Storage Service (S3).
- Part 3 compares and contrasts the two services.
Background
If you’re looking for easy “off-site” backups of your Oracle databases these days (likely to compliment your onsite backup strategy), fortunately there’s a wealth of options for you. Both Amazon Web Services (AWS) and Oracle Cloud Database Backup Service (ODBS) make the process of backing up directly to the cloud fairly easy, meaning you can go from zero to backed-up to the cloud in just a matter of a couple of hours. And both use a dynamic and very affordable “pay-as-you-go” pricing model.
So if your boss comes to you one morning and says “we need an off-site backup ASAP!!!” due to whatever reason (regulatory, audit, internal policies, pending volcano explosion in your area, or Godzilla sighting) it’s actually quite realistic that you can tell him/her “DONE!” by lunch.
Of course there are several dependencies on that, specifically database size, internet upload speed, and change control formalities. And don’t forget restore times (downloading backups through the internet) and your RTO. But if your database is 10.2 or higher (any edition including Standard Edition), and your operating system is Linux, Solaris, AIX, HP-UX, or Windows, the process is quite simple.
This article provides a quick start for getting up and running with Oracle RMAN backups to the Oracle Database Backup Service for users new to the service and cloud backups.
Backing up to Oracle Public Database Backup Service
Conceptually, backing up to the Oracle Database Backup Service is very simple. Once you have an Oracle Cloud account created, then you just download a RMAN cloud backup library module onto you database server and configure RMAN to use it. This article will dig into those steps in a little more detail.
Getting started with the Oracle Database Backup Service is fairly easy. But first it’s important to understand that they have two slightly different usage/billing models: “Metered” and “Non-Metered”.
With the Metered service the storage and data transfer is metered and charged based on “GB/Month” at rates starting at $0.0264 GB/Month for the storage component, with additional costs for outbound data transfer, and request commands. With the non-metered service the price is simply $33 per TB/month with an unlimited number of transfers and requests.
Regardless of whether you think that the progressively charged meter rate or the flat non-metered rate is most applicable, the overall cost is extremely low. With no up-front capital costs or licensing costs and a minimal monthly usage charge, the cloud based backup solution really does seem to offer value for the price. Although it should be noted that this is due to the extremely competitive cloud based storage options available these days from competitors at both the enterprise and consumer levels.
Backed up data (data-at-rest) is always encrypted (more on that later) and the transfer (data-in-flight) is always secured via HTTPS. And it’s protected via 3-way mirroring within the Oracle Data Centers.
Identity Domains
Oracle Cloud introduces a hierarchal logical structure. This starts with the “Oracle Cloud Account”, which typically corresponds to the organization or company. Within the “Account” is one or more “Identity Domains”. These logical constructs hold one or more unique Oracle cloud services. Users and authentication can be added to and span the identity domains but with unique access to each service.
The structure isn’t only logical as the identity domains (and the associated services) are correlated with an Oracle Data Center is a specific geographical location. Discover more information about this.
Creating an Oracle Database Backup Service Account
To get started, navigate and choose the “Try It” button for the free 30-day trial, which provides 250GB of free storage during the trail period. Here you’ll be promoted to choose which billing model you’ll want to continue with after your free-trial expires:
From there you’ll be prompted for information such as your name and address and of course your existing “Oracle Account”. Note that it is mandatory to first have an “Oracle Account” that anyone can create.
Interestingly Oracle also wants to verify your mobile phone number (so they can “verify your identity”) as part of the sign-up process unlike most other cloud providers. Presumably, so a sales associate can eventually follow-up with you.
The final step is to create a new “Cloud Account” and specify the name for the account. Not to be confused with your “Oracle.com Account” that is used on OTN and My Oracle Support – this one differs:
Here’s the interesting part: even though the sign-up page mentions a free 30-day trial (see screen-shot earlier), when actually registering the time magically doubles to 60-days:
The online documentation also says 30-days yet the service Dashboard (or sometimes called “WebUI” by Oracle) clearly shows 60-days.
It’s also interesting to note that after signing up specifically for the Database Backup Service, the trial automatically also includes most of the other Oracle Public Cloud offerings including the “Oracle Storage Cloud Service”, the “Oracle Compute Cloud Service”, the “Oracle Database Cloud Service”, the “Oracle Java Cloud Service”, and some others. All with the same 60-day trial period. Though it’s not obvious when signing up specifically for the “metered ODBS trial”, this is sort of mentioned in the online documentation:
“There are no specific trials for Oracle Database Backup Service. When you request a trial of Oracle Database Backup Service, you actually get a trial of Oracle Storage Cloud Service. Oracle Database Backup Service uses Oracle Storage Cloud Service containers to store cloud backups.”
Hence, if you’re planning to try these different services using the free-trials serially, you’re out of luck. You get the one 60-day window for all services running in parallel. But you can start a new trial under a separate & new identity domain. After submitting, the order should take less than an hour to complete after which you’ll receive an email with further details. This is where it gets a little confusing. You now have an “Oracle.com Account” used for OTN, MOS, etc., which is based on your email address and has a password as well as an “Oracle Cloud Administrator Account”. This is also based on that same email address but has a different password (temporary password is in the email). Log on to your Oracle Cloud account as logging in and navigating from cloud.oracle.com is confusing.
Creating Users
Creating individual users or credentials to use with the RMAN backup through secured wallet files is not at all obvious at first (unlike the competitive offering from Amazon Web Services, which is discussed in the next article in this series).
From the main dashboard at this point it’s not simple to setup credentials to be used specifically and exclusively by the RMAN backup scripts. Instead by pressing the “Security” button in the top right you can add additional administrators to your Oracle Cloud account, but each is tied to an Oracle.com account.
The trick is that you need to navigate into the dashboard specific for the identity domain! One way to do this is to find the Backup Service from the main dashboard, click on the menu option on the far right and choose “My Services”:
You’ll then be prompted with a new login window specific to the Identity Domain:
Specify, the required Identity Domain or the one chosen (or default one used) when signing up – this is also in your welcome email that can be re-sent from the same menu. After specifying the Identity Domain, log in using your Oracle Cloud Account credentials, not your Oracle.com account credentials (even though the two emails are the same)!
The Identity Domain dashboard looks almost identical to the main Oracle Cloud dashboard, though one noticeable exception is that there’s now a “Users” button along the top:
From here we can add new users and assign them specific roles such as the ability to read, write, or administer database backups:
However the disadvantage here is that these are actual “users” and not just keys and secure credentials as Amazon Web Services Identity Access Module provides.
Installing the “Oracle Database Cloud Backup Module”
To start using the service with RMAN, you’ll first need to download and install the Oracle Database Cloud Backup Module into each Oracle Home. The process is easy enough: start by downloading the installer zip file and then copying the enclosed Java JAR file to your database server. This is a generic installer which will determine the database version and OS platform/release and will install the appropriate library module. The key dependency is Java which you will already have in the Oracle home.
Installation is simple and required as mandatory arguments:
- The service name for the ODBS account (which is actually “Storage” even though ODBS doesn’t count against OPC Storage).
- The identity domain for the ODBS account.
- The user name for the ODBS account (not the Oracle.com user).
- The password for the ODBS account (not the Oracle.com user’s password).
- The location for the secure wallet file which stores the ODBS credentials.
Other options such as proxy server details can also be specified. Storing the library in the $ORACLE_HOME/lib directory (specified via the “libDir” argument) is recommended. Details of all options and arguments can be found in the README file or by running the Java JAR file without any arguments.
Example of installation:
After running, the appropriate library file is downloaded, the configuration file created, and a secure wallet file (with the credentials) created:
There are other optional customizations that can be added to the configuration file (discussed later), but at this point the initial configuration is complete and RMAN backups to the ODBS can be made.
Using with RMAN
Actually writing the backups to the ODBS is now as simple as configuring and backing up to the SBT_TAPE backup device.
For example, with all RMAN “CONFIGURE” parameters set to their default values, to backup using ODBS in a single RMAN run block without any permanent configuration changes we can try:
This error is not unexpected and brings us to a unique feature of the ODBS – backup encryption is mandatory. RMAN backups to disk require the Advanced Security Option in order to use encryption but RMAN backups using the “Oracle Secure Backup SBT interface” does not. Similarly, the “Oracle Database Cloud Backup Module” is effectively just a customized version of the Oracle Secure Backup SBT interface and also does not require the Advanced Security Option.
The required encryption can be implemented one of these ways:
- Password-based encryption – simple but requires the password to be entered manually on backup and restore.
- Transparent encryption where the encryption password is stored in an Oracle wallet.
- Dual-mode encryption where either a wallet or supplied password can be used.
Oracle recommends transparent encryption using a wallet and considers it more secure as no passwords are required.
However, using password encryption just for simplicity to start, we only have to add one simple RMAN command prior to the run block:
Voila: Encrypted backups straight to the cloud via ODBS. Additional commands such as RESTORE, RECOVER, CROSSCHECK, DELETE BACKUP, etc. all work in exactly the same way – the ODBS simply appears to RMAN as a SBT_TAPE device.
Now if we want all backups to use the ODBS without having to manually specify the SBT device parameters in a channel allocation each time we can simply persist the configuration using the CONFIGURE command:
RMAN provides various encryption algorithms (listed in the V$RMAN_ENCRYPTION_ALGORITHMS view) and all are applicable to the ODBS backups.
Another marketed benefit of ODBS is compression. “Basic Compression” (CONFIGURE COMPRESSION ALGORITHM ‘BASIC’;) can be used for all RMAN backups without the requirement for additional licensing (Source).The Oracle Advanced Compression Option allows for RMAN compression to include the additional compression levels “HIGH”, “MEDIUM”, and “LOW”. High compresses the most and results in the minimal amount of data transferred through the network (likely ideal for backing up through the internet), but at the expense of higher local CPU resources.
Therefore, a few additional permutations of the sample backup would be:
Comparing the backup performance and compression of FULL database backups using:
- Uncompressed backup to DISK
- Uncompressed backup to ODBS
- COMPRESSION=’BASIC’ to ODBS
- COMPRESSION=’HIGH’ to ODBS
Clearly the compression helps significantly in terms of output bytes and the elapsed backup time. And the ODBS unique advantage of being able to specify COMPRESSION=‘HIGH’ makes a noticeable difference on my system at the expense of CPU resources.
But drilling into the details of this test any further is of little value as there are so many site and system specific variables in play. Specifically:
- Database backup size
- Nature and compressibility of the data
- Backup parallelism or number of channels chosen
- Internet upload bandwidth
- Available CPU resources and headroom for compressing
So, similar tests should be performed on each system to find the sweet spot between compression, space used, and backup elapsed time.
Additional Considerations
Some more advanced options would included generating a detailed trace file of the OPC module by adding the “_OPC_TRACE_LEVEL=100” parameter to configuration (.ora) file. The resulting trace file is created in the ADR rdbms trace directory.
Other documented parameters that can be included in the config file are:
Further, searching the OPC library module shows many additional hidden parameters (an examination of each is outside of the scope of this article):
Oracle Database Standard Edition
Oracle Database Standard Edition historically did not support backup encryption, yet ODBS supports Standard Edition and with ODBS encryption is mandatory. Oracle created the following bug to document that contradiction:
“Bug 18339044 – Support encryption on oracle public cloud sbt library in standard edition (Doc ID 18339044.8)”
A one-off patch for this bug is available for Oracle database 10.2.0.5 onward on all ODBS supported platforms. And fortunately the patch can be applied without outage.
However depending on how up to date you are with PSU patching this may be a moot point as this bug fix is included with the following PSUs or server patch sets/bundles:
12.1.0.2 (Server Patch Set)
11.2.0.4.5 (Jan 2015) Database Patch Set Update (DB PSU)
11.2.0.4 Bundle Patch 6 for Exadata Database
11.2.0.3 Bundle Patch 23 for Exadata Database
11.2.0.4 Patch 12 on Windows Platforms
11.2.0.3 Patch 33 on Windows Platforms
11.2.0.4.5 (Jan 2015) Database Patch Set Update (DB PSU)
11.2.0.4 Bundle Patch 6 for Exadata Database
11.2.0.3 Bundle Patch 23 for Exadata Database
11.2.0.4 Patch 12 on Windows Platforms
11.2.0.3 Patch 33 on Windows Platforms
Viewing data usage
Viewing the amount of data used is quite simple from the Oracle Cloud Dashboard:
Note that this storage is not reflected as part of the “Oracle Storage Cloud Service” – they are treated as separate.
Drilling down into the “Oracle Database Backup Service” details:
Some interesting observations from this:
- The data is not real-time as the report can only show up to the prior day (“yesterday”). It doesn’t show the current day’s activities.
- There’s no further drill down, no way to tell which files/backup pieces or databases (if backing up many) are consuming the space.
- There’s not much else in the way of details or anything else we can do from the web dashboard interface except for exporting the usage numbers graphed to a CSV file. We need to use other mechanisms (including RMAN commands) to obtain further details.
Note that the above screen-shots are from the Oracle Cloud Account level, which shows all Identity Domains for the account. It’s also possible to log into the dashboard for just a single Identity Domain. However, currently this doesn’t add any additional functionality or level of detail through the web interface.
Conclusion
The Oracle Database Backup Service definitely is a simple, low-cost, and effective off-site backup solution. No upfront costs and extremely reasonable metered usage rates make it extremely competitive.
And forcing backups to the service to be encrypted (and transferred via HTTPS), while the keeping the encryption key in a wallet maintained on your on-premise device makes the configuration secure. And protected as long as the wallet file is backed up and secured separately.
Oracle’s triple-mirroring of the data in their data centers is nice, however there’s no option to choose which of the 19 Oracle data centers is used.
The position of the “special-use licensing” for the encryption and compression backup options at no additional cost may not be as much of a unique advantage as initially thought. Backup encryption to competing cloud services through the Oracle Secure Backup SBT module is already permitted as is “BASIC” level backup compression for all RMAN backups, both without additional licenses (specifically the Advanced Security Option or the Advanced Compression Option). Whether the advanced compression options provided as part of the “special-use licensing”, such as “HIGH” compression is of significant value will vary on a case-by-case or site-by-site basis.
But the key difference on the licensing front is that there is no requirement for the Oracle Secure Backup module which is separately licensed per RMAN channel (Source). This is likely the reason why the product name, modules, etc make no reference of “Oracle Secure Backup” or OSB.
DYI solutions of backing up to disk, then encrypting and possibly compressing those RMAN backup pieces separately, then uploading to any one of the many cloud storage providers adds manual steps, complexity, and possible failure points and lacks the full RMAN integration for reporting, piece management, and recovery. Conversely the ODBS only requires some very minor RMAN configuration options or adjustments to existing RMAN commands and scripts.
Many parts of the Oracle Cloud service offering is confusing at first. Specifically, the difference between the Oracle.com account and Oracle Cloud Account both based on the same email as the username. Next, the concept of Identity Domains and how to navigate to them and between them or between the dashboards and services pages certainly could be more obvious.
Beyond that WebUI for the actual ODBS is basic and provides a minimal amount of functionality and information. But probably because of the reasoning that you really don’t need any further information. Details on backup pieces and space usage can be obtained through RMAN commands and/or SQL queries. However, it would be nice to be able to graphically see through the WebUI at least which backups, or which databases are consuming the space. Instead you just get a single “space used” number graphed by day. Excluding the current day!
So overall this is probably one of the easiest and cost effective ways of writing secured and compressed database backups to an off-site location (as long as your RTO with the slower restore/download times can still be met). The fact that encryption is included without needing licenses for the Oracle Secure Backup module seems to be the “killer feature”. The additional backup compression options is a bonus on top of that.
Additional References
- My Oracle Support: “Oracle Database Backup Service – FAQ (Doc ID 1640149.1)”
Discover more about our expertise in Oracle and Cloud.
Interested in working with Simon? Schedule a tech call.