Best practice for RAC RMAN backup

I have a 10gR2 RAC db that is 3.5TB. It is a 2 node cluster on AIX. Each instance is db1 on node1, and db2 on node2, the "world" database name is db.
Currently we are doing our backup from 1 node of the cluster, specifying that it connect to to db2, so this instance is doing all of the backup work. We allocate 14 channels to back this database up to tape (yes, we have plenty of tape resources, connecting to a tape machine with > 20 physical tape drives). Would it be better to have our rman script connect to the general database db and let the listener decide which instance to send the channel allocation to, or keep all the work on one node.

I seem to remember that when I was reading up on RAC and RMAN a couple of years ago (maybe up to 4 years ago) that there was something about always doing backups from the same node in a RAC configuration i.e. you have logically 'db' in your network configuration and also direct names of 'db1' and 'db2', and you should always use one of 'db1' or 'db2' but never 'db'. And I also mean do not alternate between 'db1' and 'db2'. Pick one of them and always do your backups from that instance.
I think this was to do with things like the database identifier, and the instance identifier too, which RMAN reads and puts into the backup. It also affects things like reading the archive logs, which must be cross mounted to both nodes. I have this feeling that using the same node kept a kind of consistency within the backups, and meant that Oracle was getting all of the block images from one node i.e. from one of the SGAs. If you used both nodes simultaneously you could run into issues with their SGAs being out of sync. I know this does not make much sense, given that RAC is all about keeping the SGAs consistent with each other. But at the end of the day I do remember something about always using one node all the time to do your RMAN backups.
Not sure if these rules hold true if you are using ASM, which itself is shared in a RAC environment.
Things may have moved on since then, but that was still 10g Release 2 documentation, so I would guess it is still true. At the end of the day, it is not the backup that is important, but the recovery. You don't want to create any kind of inconsistent backup that RMAN cannot successfully recover, even though the backup may look good when you create it.
I'd check out the RMAN and RAC documentation further to see if this is supported.
John

Similar Messages

Best practice for RAC connections

Got a question of what people consider best practice for setting up high-availability connection pools to a RAC cluster. Now that you can specify the fail-over logic right in the thin connection string it seems like there are three options.
A) Use OCI connections and allow the fail-over logic to be maintained in the TNSNAMES.ORA file.
B) Use simple thin connections with multi-pools and let WebLogic maintain the fail-over logic.
C) Use simple thin connections with fail-over logic in the connection string.
Thanks,
Rodger...

If you need XA, then follow the WebLogic documentation. If not, then
you have much more freedom. The thin driver can be configured to
use the tnsnames.ora file if that helps you. WebLogic much prefers the
thin driver to the OCI-based one, which can kill a JVM with OCI bugs.
If you do driver-level failover, each failed connection will cost a test
and replace. If you use multipools, WLS can be configured to flush a
whole pool when it finds a connection bad, and also make the failover
at the pool level, right then, so application delay is minimized.
Joe

Best practice for RAC planned downtime maintenance?

I have a 3 node RAC on Linux redhat. DB version is 11gr2.
I want to know the steps to perform each node OS patch upgrade.
I want to be sure I did right steps:
1). Node 1, stop crs and do the OS patch upgrade.
2). same steps for Node 2, 3.
Is this right?
Thank you for any help.

user569151 wrote:
I have a 3 node RAC on Linux redhat. DB version is 11gr2.
I want to know the steps to perform each node OS patch upgrade.
I want to be sure I did right steps:
1). Node 1, stop crs and do the OS patch upgrade.
2). same steps for Node 2, 3.
If your RAC environment is configured properly follow this step:
Node 1:
* Relocate services to node 2 or 3 and stop database instance and service using SRVCTL
* Stop Clusterware using CRSCTL
* Disable automatic Startup of Clusterware on this node using CRSCTL
* Patch your OS
* Relink Oracle Binaries (Grid Infrastructure/Oracle Database) (P.S You will need unlock and re-lock your Grid Home to relink binaries see note RAC: Frequently Asked Questions [ID 220970.1])
If you are using ACFS you must check if that OS Upgrade will affect ACFS drivers (ACFS Supported On OS Platforms. [ID 1369107.1])
* Enable Automatic Startup of Clusterware on this node using CRSCTL
* Start Clusterware using CRSCTL
* Start Database and Services with SRVCTL
Repeat steps above on Node 2 and 3
Of course don't forget a good plan to backup and recovery to support case of failure.
http://docs.oracle.com/cd/E11882_01/server.112/e17157/planned.htm#CJACDIJD
Is It Necessary To Relink Oracle Following OS Upgrade? [ID 444595.1]
My concern is here, let's say each node has to be restarted.
So my procedure should be on 1st node: crsctl stop crs to stop everything and failover everything to other nodes.
I wonder crsctl stop crs will cause ASM instance to be down?Yes "CRSCTL STOP CRS" will try stop all clusterware resource with clean state. If any problem occurs will be raised on your prompt.
Regards,
Levi Pereira
Edited by: Levi Pereira on Nov 1, 2012 7:35 PM

Best practice for E-business suite 11i or R12 Application backup

Hi,
I'm taking RMAN backup of database. What would be "Best practice for E-business suite 11i or R12 Application backup" procedure?
Right now I'm taking file level backup. Please suggest if any.
Thanks

Please review the following thread, it should be helpful.
Reommended backup and recovery startegy for EBS
Reommended backup and recovery startegy for EBS

Kernel: PANIC! -- best practice for backup and recovery when modifying system?

I installed NVidia drivers on my OL6.6 system at home and something went bad with one of the libraries. On reboot, the kernel would panic and I couldn't get back into the system to fix anything. I ended up re-installing the OS to recovery my system.
What would be some best practices for backing up the system when making a change and then recovering if this happens again?
Would LVM snapshots be a good option? Can I recovery a snapshot from a rescue boot?
EX: File system snapshots with LVM | Ars Technica -- scroll down to the section discussing LVM.
Any pointers to documentation would be welcome as well. I'm just not sure what to do to revert the kernel or the system when installing something goes bad like this.
Thanks for your attention.

There is often a common misconception: A snapshot is not a backup. A snapshot and the original it was taken from initially share the same data blocks. LVM snapshot is a general purpose solution which can be used, for example, to quickly create a snapshot prior to a system upgrade, then if you are satisfied with the result, you would delete the snapshot.
The advantage of a snapshot is that it can be used for a live filesystem or volume while changes are written to the snapshot volume. Hence it's called "copy on write (COW), or copy on change if you want. This is necessary for system integrity to have a consistent data status of all data at a certain point in time and to allow changes happening, for example to perform a filesystem backup. A snapshot is no substitute for a disaster recovery in case you loose your storage media. A snapshot only takes seconds, and initially does not copy or backup any data, unless data changes. It is therefore important to delete the snapshot if no longer required, in order to prevent duplication of data and restore file system performance.
LVM was never a great thing under Linux and can cause serious I/O performance bottlenecks. If snapshot or COW technology suits your purpose, I suggest you look into Btrfs, which is a modern filesystem built into the latest Oracle UEK kernel. Btrfs employs the idea of subvolumes and is much more efficient that LVM because it can operate on files or directories while LVM is doing the whole logical volume.
Keep in mind however, you cannot use LVM or Btrfs with the boot partition, because the Grub boot loader, which loads the Linux kernel, cannot deal with LVM or BTRFS before loading the Linux kernel (catch22).
I think the following is an interesting and fun to read introduction explaining basic concepts:
http://events.linuxfoundation.org/sites/events/files/slides/Btrfs_1.pdf

Best practice for bi backup

Hi,
Who can suggest me the best practice for backup/restore of entire bi dashboard reports, permissions and etc?
Ed,

Hi,
If you want move the entire dashboards,reports ,permissions
Zip the *<OracleBIData>Web/catalog* folder and move it new environment. In new envornment unzip this catalog and in Instanceconfig.xml mention the path for this new catalog.
If you want move the few dashboads or reports ,do it by Catalog Manager.
Thank you.

Best practice for installation oracle 11g rac on windows 2008 server x64

hello!
can somebody tell me a good book or an other kind of literature regarding "best practice for installation oracle 11g rac on windows 2008 server x64"? thx in advance!
best regards,
christian

Hi Christian,
Check this on MOS
*RAC Assurance Support Team: RAC Starter Kit and Best Practices (Windows) [ID 811271.1]*
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=BULLETIN&id=811271.1
DOC Modified: 14-DEC-2010
Regards,
Levi Pereira

What is best practice for deploying agent(10204) on RAC 9i

Hello,
What would be best practice for deploying agent(10204) on RAC 9i? Should the agent be deployed on each node or should the agent be deployed on the cluster file system? What are the advantages/disavantages deploy on individual nodes vs. on cluster file system? Please advice. Thank you in advance.

Please use agent push application to deploy agent on all the nodes at one shot
Please refer the obe
http://www.oracle.com/technology/obe/obe10gemgc_10203/agentpush/agentpush.htm

ASM on SAN datafile size best practice for performance?

Is their a 'Best Practice' for datafile size for performance?
In our current production, we have 25GB datafiles for all of our tablespaces in ASM on 10GR1, but was wondering what the difference would be if I used say 50GB datafiles? Is 25GB a kind of mid point so the data can be striped across multiple datafiles for better performance?

We will be using Redhat Linux AS 4 update u on 64-bit AMD Opterons. The complete database will be on ASM...not the binarys though. All of our datafiles we have currently in our production system are all 25GB files. We will be using RMAN-->Veritas Tape backup and RMAN-->disk backup. I just didn't know if anybody out there was using smallfile tablespaces using 50GB datafiles or not. I can see that one of our tablespaces will prob be close to 4TB.

Best Practices for Using Photoshop (and Computing in General)

I've been seeing some threads that lead me to realize that not everyone knows the best practices for doing Photoshop on a computer, and in doing conscientious computing in general. I thought it might be a good idea for those of us with some exprience to contribute and discuss best practices for making the Photoshop and computing experience more reliable and enjoyable.
It'd be great if everyone would contribute their ideas, and especially their personal experience.
Here are some of my thoughts on data integrity (this shouldn't be the only subject of this thread):
Consider paying more for good hardware. Computers have almost become commodities, and price shopping abounds, but there are some areas where spending a few dollars more can be beneficial. For example, the difference in price between a top-of-the-line high performance enterprise class hard drive and the cheapest model around with, say, a 1 TB capacity is less than a hundred bucks! Disk drives do fail! They're not all created equal. What would it cost you in aggravation and time to lose your data? Imagine it happening at the worst possible time, because that's exactly when failures occur.
Use an Uninterruptable Power Supply (UPS). Unexpected power outages are TERRIBLE for both computer software and hardware. Lost files and burned out hardware are a possibility. A UPS that will power the computer and monitor can be found at the local high tech store and doesn't cost much. The modern ones will even communicate with the computer via USB to perform an orderly shutdown if the power failure goes on too long for the batteries to keep going. Again, how much is it worth to you to have a computer outage and loss of data?
Work locally, copy files elsewhere. Photoshop likes to be run on files on the local hard drive(s). If you are working in an environment where you have networking, rather than opening a file right off the network, then saving it back there, consider copying the file to your local hard drive then working on it there. This way an unexpected network outage or error won't cause you to lose work.
Never save over your original files. You may have a library of original images you have captured with your camera or created. Sometimes these are in formats that can be re-saved. If you're going to work on one of those files (e.g., to prepare it for some use, such as printing), and it's a file type that can be overwritten (e.g., JPEG), as soon as you open the file save the document in another location, e.g., in Photoshop .psd format.
Save your master files in several places. While you are working in Photoshop, especially if you've done a lot of work on one document, remember to save your work regularly, and you may want to save it in several different places (or copy the file after you have saved it to a backup folder, or save it in a version management system). Things can go wrong and it's nice to be able to go back to a prior saved version without losing too much work.
Make Backups. Back up your computer files, including your Photoshop work, ideally to external media. Windows now ships with a quite good backup system, and external USB drives with surprisingly high capacity (e.g., Western Digital MyBook) are very inexpensive. The external drives aren't that fast, but a backup you've set up to run late at night can finish by morning, and if/when you have a failure or loss of data. And if you're really concerned with backup integrity, you can unplug an external drive and take it to another location.
This stuff is kind of "motherhood and apple pie" but it's worth getting the word out I think.
Your ideas?
-Noel

APC Back-UPS XS 1300. $169.99 at Best Buy.
Our power outages here are usually only a few seconds; this should give my server about 20 or 25 minutes run-time.
I'm setting up the PowerChute software now to shut down the computer when 5 minutes of power is left. The load with the monitor sleeping is 171 watts.
This has surge protection and other nice features as well.
-Noel

Best Practices for new iMac

I posted a few days ago re failing HDD on mid-2007 iMac. Long story short, took it into Apple store, Genius worked on it for 45 mins before decreeing it in need of new HDD. After considering the expenses of adding memory, new drive, hardware and installation costs, I got a brand new iMac entry level (21.5" screen,
2.7 GHz Intel Core i5, 8 GB 1600 MHz DDR3 memory, 1TB HDD running Mavericks). Also got a Superdrive. I am not needing to migrate anything from the old iMac.
I was surprised that a physical disc for the OS was not included. So I am looking for any Best Practices for setting up this iMac, specifically in the area of backup and recovery. Do I need to make a boot DVD? Would that be in addition to making a Time Machine full backup (using external G-drive)? I have searched this community and the Help topics on Apple Support and have not found any "checklist" of recommended actions. I realize the value of everyone's time, so any feedback is very appreciated.

OS X has not been officially issued on physical media since OS X 10.6 (arguably 10.7 was issued on some USB drives, but this was a non-standard approach for purchasing and installing it).
To reinstall the OS, your system comes with a recovery partition that can be booted to by holding the Command-R keys immediately after hearing the boot chimes sound. This partition boots to the OS X tools window, where you can select options to restore from backup or reinstall the OS. If you choose the option to reinstall, then the OS installation files will be downloaded from Apple's servers.
If for some reason your entire hard drive is damaged and even the recovery partition is not accessible, then your system supports the ability to use Internet Recovery, which is the same thing except instead of accessing the recovery boot drive from your hard drive, the system will download it as a disk image (again from Apple's servers) and then boot from that image.
Both of these options will require you have broadband internet access, as you will ultimately need to download several gigabytes of installation data to proceed with the reinstallation.
There are some options available for creating your own boot and installation DVD or external hard drive, but for most intents and purposes this is not necessary.
The only "checklist" option I would recommend for anyone with a new Mac system, is to get a 1TB external drive (or a drive that is at least as big as your internal boot drive) and set it up as a Time Machine backup. This will ensure you have a fully restorable backup of your entire system, which you can access via the recovery partition for restoring if needed, or for migrating data to a fresh OS installation.

Best practice for migrating IDOCs?

Subject: Best practice for migrating IDOC's?
Hi,
I need to migrate some IDOC's to another system for 'historical reference'.
However, I don't want to move them using the regular setup as I don't want the inbound processing to be triggered.
The data that was created in the original system by the processed IDOC's will be migrated to the new system using migration workbench. I only need to migrate the IDOC's as-is due to legal requirements.
What is the best way to do this? I can see three solutions:
A) Download IDOC table contents to a local file and upload them in the new system. Quick and dirty approach, but it might also be a bit risky.
B) Use LSMW. However, I'm not sure whether this is feasible for IDOC's.
C) Using ALE and setting up a custom partner profile where inbound processing only writes the IDOC's to the database. Send the IDOC's from legacy to the new system. Using standard functionality in this way seems to me to be the best solution, but I need to make sure that the IDOC's once migration will get the same status as they had in the old system.
Any help/input will be appreciated
Regards
Karl Johan
PS. For anyone interested in the business case: Within EU the utility market was deregulated a few years ago, so that any customer can buy electricity from any supplier. When a customer switches supplier this is handled via EDI, in SAP using ALE and IDOC's. I'm working on a merger between two utility companies and for legal reasons we need to move the IDOC's. Any other data is migrated using migration workbench for IS-U.

Hi Daniele
I am not entirely sure, what you are asking, Please could you provide additional information.
Are you looking for best practice recommendations for Governance, for example: Change transports between DEV, QA and PRD in BPC 7.0?
What is the best method? Server Manager backup and restore, etc ?
And
Best Practice recommendations on how to upgrade to a different version of BPC, for example: Upgrading from BPC 7.0 to 7.5 or 10.0 ?
Kind Regards
Daniel

Best practice for distributing/releasing J2EE applications.

Hi All,
We are developing a J2EE application and would like some information on the best
practices to be followed for distributing/releasing J2EE applications, in general.
In particular, the dilemma we have is centered around the generation of stub, skeleton
and additional classes for the application.
Most App. Servers can generate the required classes while deploying the EJBs in the
application i.e. at install time. While some ( BEA Weblogic and IBM Websphere are
two that we are aware of ) allow these classes to be generated before the installation
time and the .ear file containing the additional classes is the one that is uploaded.
For instance, say we have assembled the application "myapp.ear" . There are two ways
in which the classes can be generated. The first is using 'ejbc' ( assume we are
using BEA Weblogic ), which generates the stub, skeleton and additional classes for
the application and returns the file, say, "Deployable_myapp.ear" containing all
the necessary classes and files. This file is the one that is then installed. The
other option is to install the file "myapp.ear" and let the Weblogic App. server
itself, generate the required classes at the installation time.
If the first way, of 'pre-generating' the stubs is followed, does it require us to
separately generate the stubs for each versions of the App. Server that we support
? i.e. if we generate a deployable file having the required classes using the 'ejbc'
of Weblogic Ver5.1, can the same file be installed on Weblogic Ver6.1 or do we
have to generate a separate file?
If the second method, of 'install-time-generation' of stubs is used, what is the
nature/magnitude of the risk that we are taking in terms of the failure of the installation
Any links to useful resources as well as comments/suggestions will be appreciated.
TIA
Regards,
Aasif

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

What are best practice for packaging and deploying j2EE apps to iAS?

We've been running a set of J2EE applications on a pair of iAS SP1b for about a year and it has been quite stable.
Recently however we have had a number of LDAP issues, particularly when registering and unregistering applications (registering ear files sometimes fails 1st time but may work 2nd time). Also We've noticed very occasionally that old versions of classes sometimes find their way onto our machines.
What is considered to be best practice in terms of packaging and deployment, specifically:
1) Packaging - using the deployTool that comes with iAS6 SP1b to package is a big manual task, especially when you have 200+ jsp files. Are people out there using this or are they scripting it with a build tool such as Ant?
2) Deploying an existing application to multiple iAS's. Are you guys unregistering old application then reregistering new application? Are you shutting down iAS whilst doing the deployment?
3) Deploying ear files can take 5 to 10 mins, is this normal?
4) In a clustered scenario where HTTPSession is shared what are the consequences of doing deployments to data stored in session?
thanks in asvance for your replies
Owen

You may want to consider upgrading your application server environment to a newer service pack. There are numerous enhancements involving the deployment tool and run time layout of your application that make clear where you're application is loading its files from.
If you've at a long running application server environment, with lots of deployments under your belt, you might start to notice slow downs in deployment and kjs start time. Generally this is due to garbage collecting in your iAS registry.
You can do several things to resolve this. The most complete solution is to reinstall the application server. This will guarantee a clean ldap registry. Of course you've got to restablish your configurations and redeploy your applications. When done, backup your application server install space with the application server and directory server off. You can use this backup to return to a known configuation at some future time.
For the second method: <B>BE CAREFUL - BACKUP FIRST</B>
There is a more exhaustive solution that involves examining your deployed components to determine the active GUIDS. You then search the NameTrans section of the registry searching for Applogic Servlet *, and Bean * entries that represent your previously deployed components but are represented in the set of deployed GUIDs. Record these older GUIDs, remove them from ClassImp and ClassDef. Finally remove the older entries from NameTrans.
Best practices for deployment depend on your particular environmental needs. Many people utilize ANT as a build tool. In later versions of the application server, complete ANT scripts are included that address compiling, assembly and deployment. Ant 1.4 includes iAS specific targets and general J2EE targets. There are iAS specific targets that can be utilized with the 1.3 version. Specialized build targets are not required however to deploy to iAS.
Newer versions of the deployment tool allow you to specify that JSPs are not to be registered automatically. This can be significant if deployment times lag. Registered JSP's however benefit more fully from the services that iAS offers.
2) In general it is better to undeploy then redeploy. However, if you know that you're not changing GUIDs, recreating an existing application with new GUIDs, or removing registered components, you may avoid the undeploy phase.
If you shut down the KJS processes during deployment you can eliminate some addition workload on the LDAP server which really gets pounded during deployment. This is because the KJS processes detect changes and do registry loads to repopulate their caches. This can happen many times during a deployment and does not provide any benefit.
3) Deploying can be a lengthy process. There have been improvements in that performance from service pack to service pack but unfortunately you wont see dramatic drops in deployment times.
One thing you can do to reduce deployment times is to understand the type of deployment. If you have not manipulated your deployment descriptors in any way, then there is no need to deploy. Simply drop your newer bits in to the run time space of the application server. In later service packs this means exploding the package (ear,war, or jar) in to the appropriate subdirectory of the APPS directory.
4) If you've changed the classes of objects that have been placed in HTTPSession, you may find that you can no longer utilize those objects. For that reason, it is suggested that objects placed in session be kept as simple as possible in order to minimize this effect. In general however, is not a good idea to change a web application during the life span of a session.

Best practice for a deplomyent (EAR containing WAR/EJB) in a productive environment

Hi there,
I'm looking for some hints regarding to the best practice deployment in a productive
environment (currently we are not using a WLS-cluster);
We are using ANT for buildung, packaging and (dynamic) deployment (via weblogic.Deployer)
on the development environment and this works fine (in the meantime);
For my point of view, I would like to prefere this kind of Deploment not only
for the development, also for the productive system.
But I found some hints in some books, and this guys prefere the static deployment
for the p-system.
My question now:
Could anybody provide me with some links to some whitepapers regarding best practice
for a deployment into a p-system ??
What is your experiance with the new two-phase-deploment coming up with WLS 7.0
Is it really a good idea to use the static deployment (what is the advantage of
this kind of deployment ???
THX in advanced
-Martin

Hi Siva,
What best practise are you looking for ? If you can be specific on your question we could provide appropriate response.
From my basis experience some of the best practices.
1) Productive landscape should have high availability to business. For this you may setup DR or HA or both.
2) It should have backup configured for which restore has been already tested
3) It should have all the monitoring setup viz application, OS and DB
4) Productive client should not be modifiable
5) Users in Production landscape should have appropriate authorization based on SOD. There should not be any SOD conflicts
6) Transport to Production should be highly controlled. Any transport to Production should be moved only with appropriate Change Board approvals.
7) Relevant Database and OS security parameters should be tested before golive and enabled
8) Pre-Golive , Post Golive should have been performed on Production system
9) EWA should be configured atleast for Production system
10) Production system availability using DR should have been tested
Hope this helps.
Regards,
Deepak Kori

Best practice for RAC RMAN backup

Similar Messages

Maybe you are looking for