Re: oracle on EC2

From: Jeremiah Cetlin Wilton <jcwilton93_at_earlham.edu>
Date: Mon, 11 Jan 2016 13:50:19 -0500 (EST)
Message-ID: <196375225.34216787.1452538219303.JavaMail.root_at_earlham.edu>



Hi Max,

Well first of all, there's a service that does that for you (and lots of other things). It's called RDS ;-)

https://aws.amazon.com/rds/oracle/

If RDS doesn't suit your use case, first of all let me know what's missing.

Generally regarding taking snapshot backups of Oracle on striped EBS, you'll have to engineer a solution yourself. You will need some tooling that keeps track of what volumes belong to which databases. If you consolidate databases on the same EBS volumes, your tooling will need to be smart enough to do the right thing in that case too.

In a nutshell, it's what I mentioned in my last post:

For backup, write tooling to:

  1. Put the DB in backup mode
  2. Take snapshots of all the volumes where the datafiles reside
  3. Track/tag the snapshots so that your tooling will know how to restore a particular set of snapshots for a particular backup.
  4. Back up the archivelogs somewhere else frequently (dataguard or to S3 every n minutes)

For full restore/recover, write tooling to:

  1. Create new volumes in the correct availability zone from the appropriate set of snapshots that comprise a backup
  2. Detach the old volumes from the instance
  3. Attach the new volumes to the instance using the same names as the old
  4. Restore all archivelogs you need from S3 or wherever you are backing them up
  5. Start up Oracle mount, recover through the logs and away you go.

For partial restore/recover, such as single datafile, or block recovery, write tooling to:

  1. Create new volumes in the correct availability zone from the appropriate set of snapshots that comprise a backup
  2. Attach the new volumes to the instance using different names from the current
  3. Mount the new volumes in a mount point different from the current OR use renamedg on the volumes to mount them as an ASM diskgroup different from the current
  4. Restore all archivelogs you need from S3 or wherever you are backing them up
  5. Use RMAN 'catalog start with ...' on the new mount point or diskgroup and archivelogs to let RMAN know about them
  6. Do your restore/recover as normal

It's important to build automation around all of this, or else you'll likely be fumbling around in the event of a crisis.

There are also third party options, that can back up Oracle to S3 block by block using SBT, but I think most of them are costly.

Jeremiah

PS. I'm looking for great database engineers to work in in Seattle or Vancouver BC.

  • Original Message -----

From: "max scalf" <oracle.blog3_at_gmail.com> To: "Jeremiah Cetlin Wilton" <jcwilton93_at_earlham.edu> Cc: "Maris Elsins" <elmaris_at_gmail.com>, "Oracle Mailing List" <oracle-l_at_freelists.org> Sent: Monday, January 11, 2016 9:59:27 AM Subject: Re: oracle on EC2

Thanks Maris and Jeremiah.

Our volume size were about 600GB each, so we had had good about amount of baseline IOPS and some our bursting capabilities.

_at_Jeremiah,

I was wondering if you can point me in a good direction with regards to having to take a snapshot when volumes are stripped in an oracle environment and how do we go about restore that back?

On Mon, Jan 11, 2016 at 11:40 AM, Jeremiah Cetlin Wilton < jcwilton93_at_earlham.edu > wrote:

Hi Max

What size were your gp2 volumes? You should pay close attention to the relationship between volume size and performance as described here:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Regarding backups,old-fashioned database/tablespace backup mode should work fine. It doesn't just apply to striping. It also applies if you have created datafiles for a particular tablespace on different volumes.

To get the most out of snapshot backups in any context, it is a good idea to have a known set of procedures to present the snapshotted volumes, mount them as a filesystem or diskgroup, catalog the contents in RMAN, and use the backup for restores/recoveries. Typically you would want to be able to do this alongside a running instance (by mounting the snapshot backups as a differently named filesystem or diskgroup), so that you can use it for single datafile, single tablespace, or block-level recoveries.

Jeremiah

PS. I'm generally available to answer questions about AWS (I work there). If I can't answer a question, I can probably find you someone who can.

From: "Maris Elsins" < elmaris_at_gmail.com > To: "max scalf" < oracle.blog3_at_gmail.com > Cc: "Oracle Mailing List" < oracle-l_at_freelists.org > Sent: Monday, January 11, 2016 9:19:33 AM Subject: Re: oracle on EC2

Hi,

We created AMIs, but you can easily find that behind and AMI a snapshot for each EBS volume is created, and then the AMI is assembled from these snapshots. In fact when you create an AMI manually you can map with EBS volume snapshots to use for the target EBS volumes of the new instance. (What I want to say is that it shouldn't matter if you create AMI or just a snapshot) In our case each EBS volume is an ASM disk, so when we create our clone instance we re-configure asm and the disks are discovered and the ASM diskgroups are already available. So, the data is striped, but the disks are somewhat each on it's own. I don't know if and how it would work with RAID-striped volumes.

---
Maris Elsins
_at_MarisElsins
www.facebook.com/maris.elsins

On Mon, Jan 11, 2016 at 6:30 PM, max scalf < oracle.blog3_at_gmail.com > wrote:

<blockquote>

Maris,

Thanks for the info. A follow up question, you mentioned that you take snapshot for cloning, as the volumes you are using are already stripped. Are you creating an image (AMI) or snapshot of individual volume.

Reason why i ask is, if you are taking snapshot of individual volumes(which are stripped) then restoring it, is that working alright ?? I want to see how the restore of the snapshot is work when volumes are stripped ...

On Mon, Jan 11, 2016 at 9:29 AM, Maris Elsins < elmaris_at_gmail.com > wrote:

<blockquote>

Hi,

We're running a configuration that addresses some of your IOPS concerns and it's basically one of the architectures from this whitepaper https://d0.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf

  • We have created our EC2 for Oracle DBs using Oracle Linux 6 (requirement for Oracle Smart Flash Cache)
  • We've set up ASM on multiple provisioned IOPS EBS volumes (SSD) for striping
  • We've enabled Oracle Smart Flash Cache on part of the ephemeral instance store SSD (it doesn't have even the tiny network latency that EBS volumes have, as they are local). And based on the AWR reports we see this works very well. And in fact with larger EC2 instances one gets plenty of instance store SSDs that otherwise are of no big use.)
  • We don't rely on EBS volumes' snapshots for backups, as we have a DataGuard set up and when needed we stop the recovery there and take snapshots from it (for cloning purposes usually). I'd think this would also work with "ALTER DATABASE BEGIN/END BACKUP" + simultaneous snapshot of all striped EBS volumes too.
  • We take regular RMAN backups for point in time recovery requirements.

May be this is not exactly what you were looking for as you provided a link related to RAID configurations, but probably you can still extract something useful from what I wrote.

regards,

---
Maris Elsins
_at_MarisElsins
www.facebook.com/maris.elsins

On Mon, Jan 11, 2016 at 4:44 PM, max scalf < oracle.blog3_at_gmail.com > wrote:

<blockquote>

Hello all,

This question is related to running oracle database on Amazon Web Service. Just so i respect everyone's time on here, I would say please ignore this question if you do not work with AWS.

We are running oracle some 11g and 12c database on AWS EC2 server. Most of the server have anywhere from 2 -8 EBS Volume attached(general purpose SSD), they are NOT striped or mirrored. Lately we have been seeing some performance issue(year end closing) with high IO wait time(60-80 ms per read), for some mission critical application we have moved the EBS volumes from general purpose SSD to Provisioned IOPS(PIOPS) and everything seems happy. But now we are coming back to some of the other application and our sysadmin says instead of moving everything from general purpose volumes to PIOPS we should just strip the volumes to get better performance.

I agree with him, but my question if we were to strip the EBS volumes how do we deal with taking EBS Snapshot and managing them. We rely on them for our DR in another region. From what i understand about taking snapshot when your EBS volumes are stripped is that you have to freeze the IO before you do the snapshot to guarantee EBS snapshot consistency, see below link..

https://aws.amazon.com/premiumsupport/knowledge-center/snapshot-ebs-raid-array/

So i wanted to see what others are doing in the community to achieve higher IOPS and i am sure quite a few ppl are running oracle on AWS and also I wanted to find out when they say "Freeze IO", I am assuming putting database in HOT BACKUP mode is the wrong thing.

</blockquote>

</blockquote>

</blockquote>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Jan 11 2016 - 19:50:19 CET

Original text of this message