We are running our SAP environment on this. And during the initial install
of SAP, we have to pass in the SYS credentials.
On Mon, Jan 11, 2016 at 1:42 PM, Jeremiah Cetlin Wilton <
jcwilton93@xxxxxxxxxxx> wrote:
Thanks Max
What ERP package are you using? What kinds of things does it need SYS for?
Thanks,
Jeremiah
------------------------------
*From: *"max scalf" <oracle.blog3@xxxxxxxxx>
*To: *"Jeremiah Cetlin Wilton" <jcwilton93@xxxxxxxxxxx>
*Cc: *"Maris Elsins" <elmaris@xxxxxxxxx>, "Oracle Mailing List" <
oracle-l@xxxxxxxxxxxxx>
*Sent: *Monday, January 11, 2016 11:37:01 AM
*Subject: *Re: oracle on EC2
Jeremiah,
The day you guys start providing access to SYS user i will be the first
one moving our ERP system to RDS. Until then we have to run that on EC2
instance.
Snapshot for us is only for DR purpose, as we take local snapshot and copy
that over to secondary region for DR only. I think I will have to do some
testing with regards to snapshot and restore of snapshot when volumes are
strippied. Thank you for all the info.
On Mon, Jan 11, 2016 at 12:50 PM, Jeremiah Cetlin Wilton <
jcwilton93@xxxxxxxxxxx> wrote:
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.
------------------------------
*From: *"max scalf" <oracle.blog3@xxxxxxxxx>
*To: *"Jeremiah Cetlin Wilton" <jcwilton93@xxxxxxxxxxx>
*Cc: *"Maris Elsins" <elmaris@xxxxxxxxx>, "Oracle Mailing List" <
oracle-l@xxxxxxxxxxxxx>
*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.
@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@xxxxxxxxxxx> 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@xxxxxxxxx>
*To: *"max scalf" <oracle.blog3@xxxxxxxxx>
*Cc: *"Oracle Mailing List" <oracle-l@xxxxxxxxxxxxx>
*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
@MarisElsins <https://twitter.com/MarisElsins>
www.facebook.com/maris.elsins
On Mon, Jan 11, 2016 at 6:30 PM, max scalf <oracle.blog3@xxxxxxxxx>
wrote:
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@xxxxxxxxx>
wrote:
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
@MarisElsins <https://twitter.com/MarisElsins>
www.facebook.com/maris.elsins
On Mon, Jan 11, 2016 at 4:44 PM, max scalf <oracle.blog3@xxxxxxxxx>
wrote:
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.
