RE: Questions on ASM best practices
Date: Tue, 16 Dec 2014 16:46:00 +0000
Message-ID: <1AFD62082EEAF0448EF1815139687F1324D05B1D_at_NC2PWEX504.us.ad.lfg.com>
Don't know if I can give you concrete answers on everything but, I can give some information about how our organization handles some of this.
Snapshots:
We use NetApp. To facilitate this, we have shared and Dedicated DG's
+DB_REDO = shared for all DB's. We do hot snaps and don't bother snapping our redo logs
+DB_TEMP = shared for all DB's. We do not bother snapping temp files
+<DB_NAME>_DATA = dedicated to each DB. Datafiles here...
+<DB_NAME>_CTL = dedicated to each DB. Controlfiles here...
+<DB_NAME>_ARCH = dedicated to each DB. archivelogs here...
+FRA = shared for all DB's. Only for backupsets from RMAN. Not snapped
One of the challenges with this of course is the DG limitation. As of 11g, you could only have something like 63. In 12c I think it supports 511 DG's. Another challenge we have is cloning with Snaps. When you mount a clone, it has the same DG name. If you are on the same host, you have to use "renamedg" to change the name (among other steps). One way we get around this is cloning to different servers/clusters. As long as a DB with the same name does not exist, we can cut out the step of renaming DG's. Since our REDO/TEMP DG's exist everywhere, they are all ready to go.
REDO: Because of the SAN capabilities, we use EXTERNAL redundancy everywhere. In fact, I think that is Oracle's default recommendation if you have a powerful SAN to take care of your redundancy. That may have changed in recent years but we still subscribe to it.
Despite that, our standard is to create 2 members per group. I suppose this may help in the event of physical corruption or user error removing a log before it gets archived.
Chris..
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group cruel_at_lfg.com<mailto:cruel_at_lfg.com> * Desk:317.759.2172 * Cell 317.523.8482
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hameed, Amir
Sent: Tuesday, December 16, 2014 10:17 AM
To: oracle-l_at_freelists.org
Subject: Questions on ASM best practices
Hi folks,
I am in the process of implementing ASM for the first time. I have a few questions that I would like to ask regarding ASM best practices for both single instance and RAC databases. The Grid/ASM version is 12.1.0.2:
- Redo log file placement - In the non-ASM world, I am used to using two groups for redo logs on multiple mount points with multiple log members in each group. How does this change in ASM? For an externally-managed ASM disk group, should there be multiple ASM redo disk groups with each hosting a redo log group or should one ASM redo disk group with multiple members be sufficient?
- Managing multiple databases - In the non-ASM world, we allocate a separate set of mount points for each database that we set up. This isolates an environment at the storage level and also enables us to take storage-based snapshots of a database file systems for backup. Restore is also simple and quick where we restore from the online snaps. What is the best approach to manage multiple databases in ASM? Should each DB have its own set of ASM disk groups or should all databases be placed in the same set of disk groups? For example, for databases with SIDs ABCD, MNOP & WXYZ:
o Should there be only one set of ASM disk group (DATA, REDO, RECO, etc.) for all of the above databases OR
o Should ABCD be in its own set of disk group (DATA_ABCD, REDO_ABCD, RECO_ABCO), WXYZ be in its set of disk group (DATA_WXYZ, REDO_ WXYZ, RECO_ WXYZ), etc.? This model seems to give more flexibility in terms of retiring an environment where a DG could just be dropped and a new one created when setting up a new environment, either via cloning or creating one from scratch.
- AU and stripe sizes - For an Oracle E-Business Suite type system, which is hybrid in nature, should the AU size be 1M for the DATA and REDO groups? Should the stripe size be 1M and 128k for DATA and REDO groups respectively?
Any feedback will be appreciated.
Thanks,
Amir
Notice of Confidentiality: **This E-mail and any of its attachments may contain
Lincoln National Corporation proprietary information, which is privileged, confidential,
or subject to copyright belonging to the Lincoln National Corporation family of
companies. This E-mail is intended solely for the use of the individual or entity to
which it is addressed. If you are not the intended recipient of this E-mail, you are
hereby notified that any dissemination, distribution, copying, or action taken in
relation to the contents of and attachments to this E-mail is strictly prohibited
and may be unlawful. If you have received this E-mail in error, please notify the
sender immediately and permanently delete the original and any copy of this E-mail
and any printout. Thank You.**
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Dec 16 2014 - 17:46:00 CET