Re: oracle on EC2
Date: Mon, 11 Jan 2016 13:47:53 -0600
Message-ID: <CAKoJ+qAofMh_c6SEmM6k3qi-kH9aC-iK+pzZK9aKxkUuB9wGZw_at_mail.gmail.com>
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_at_earlham.edu> 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_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 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_at_earlham.edu> 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_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 <https://twitter.com/MarisElsins>
>>> www.facebook.com/maris.elsins
>>>
>>>
>>>
>>> On Mon, Jan 11, 2016 at 6:30 PM, max scalf <oracle.blog3_at_gmail.com>
>>> 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_at_gmail.com>
>>>> 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
>>>>> _at_MarisElsins <https://twitter.com/MarisElsins>
>>>>> www.facebook.com/maris.elsins
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 11, 2016 at 4:44 PM, max scalf <oracle.blog3_at_gmail.com>
>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 11 2016 - 20:47:53 CET