Posts Tagged ‘backup’

Oracle Database : How to Backup Oracle Database using RMAN with Examples

October 28th, 2018, posted in Oracle Queries
Share

Even if you are not an Oracle DBA, you’ll still encounter a situation where you may have to take a backup of an Oracle database.

Using Oracle RMAN, you can take a hot backup for your database, which will take a consistent backup even when your DB is up and running.

This tutorial gives you an introduction on how to perform Oracle DB backup using RMAN.

For the impatient, here is the quick snippet, that takes RMAN backup of both database and archive logs.

RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

Oracle Database : How to Backup Oracle Database using RMAN with Examples,Oracle Database,How to Backup Oracle Database, using RMAN with Examples,How to Backup Oracle,Oracle,Database,Oracle Database DBA,Oracle DBA,Database DBA,Oracle Database using RMAN,RMAN Oracle Database ,Oracle Database RMAN,Backup Oracle Database,Backup,Oracle Backup

1. View Current RMAN Configuration

Before we take the backup, we have to configure certain RMAN parameters. For example, how long you want to reatain the RMAN backup, etc.

Before we modify any configuration, execute the following command to view all current RMAN configuration settings.

To connect to RMAN, do the following from command line. This will take you to RMAN> command prompt, from here you can execute all RMAN commands.

$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Sat Aug 10 11:21:29 2013
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database: DEVDB (DBID=821773)
RMAN>

To view current RMAN configurations, execute “show all”.

RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO "/backup/rman/ctl_%F";
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 2;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   "/backup/rman/full_%u_%s_%p" MAXPIECESIZE 2048 M;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2.0/dbs/snapcf_devdb.f'; # default

As you see above, it displays various RMAN parameters and their current values.

2. Change Few RMAN Configuration Parameters

Location: One of the important configuration parameters to set will be, where you want to save the RMAN backup. In the following example, I’m settting the RMAN backup loacation as “/backup/rman/”

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup/rman/full_%u_%s_%p';

Retention Period: Next, you should specify how long you want to retain the backup for. When RMAN takes a backup, it automatically deletes all the old backups that are older than the retention period. In the following example, I’m setting the retention period as 7 days, which will keep the DB backup for a week.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

Verify that the above two changes are done.

RMAN> SHOW ALL;
..
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/backup/rman/full_%u_%s_%p';
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
..

Clear a Parameter: If you want to clear a parameter and set its value to default, use CLEAR at the end of the configuration as shown below.

RMAN> CONFIGURE RETENTION POLICY CLEAR;

In this example, since we cleared the retention policy’s value, it was set to the default value, which is 1. So, the retention policy is set to 1 day as shown below.

RMAN> SHOW ALL;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

 

3. Backup Oracle Database

Make sure the directory mentioned in the CHANNEK DEVICE TYPE DISK FORMAT is created. i.e /backup/rman/

$ mkdir -p /backup/rman

Currently this directory is empty. We’ll see what this has after the backup is taken.

$ ls -l /backup/rman
total 0

We can take a backup using image copy or in backup set. It is strongly recommended to use RMAN backup sets to backup the database.

RMAN stores the backup in backup sets, which are nothing but whole bunch of files which contains the backed-up data. Only RMAN understands the format of these files. So, if you backup an Oracle DB using RMAN, only RMAN knows how to read the backup and restore it.

Typically we’ll use “BACKUP AS BACKUPSET” to backup a database. So, to take a full backup of the database without the archive logs, do the following.

RMAN> BACKUP AS BACKUPSET DATABASE

To take a full backup of the database with the archive logs, do the following:

RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;

You can also take a backup of only a specific table space. The following example takes backup of only PRD01 tablespace.

RMAN> BACKUP AS BACKUPSET TABLESPACE PRD01;

The RMAN backup output will be something similar to the following:

RMAN> BACKUP AS BACKUPSET DATABASE
Starting backup at 10-AUG-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=193 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=192 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00025 name=/u03/oradata/devdb/devuser07.dbf
input datafile fno=00003 name=/u02/oradata/devdb/temp01.dbf
channel ORA_DISK_1: starting piece 1 at 10-AUG-13
channel ORA_DISK_2: starting full datafile backupset
channel ORA_DISK_2: specifying datafile(s) in backupset
input datafile fno=00008 name=/u03/oradata/devdb/devusers05.dbf
channel ORA_DISK_2: starting piece 1 at 10-AUG-13
...
..

piece handle=/backup/rman/full_4dogpd0u_4237_1 tag=TAG20130808T114846 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 10-AUG-13
...
Starting Control File and SPFILE Autobackup at 10-AUG-13
piece handle=/backup/rman/ctl_c-758818131-20130808-00 comment=NONE
Finished Control File and SPFILE Autobackup at 10-AUG-13

Once the backup is completed, do an ls on the /backup/rman directory, you’ll now see RMAN backup files.

$ ls -l /backup/rman
total 14588
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1

Note: Once a backup is taken, to view all available database backups from RMAN, you need to use “list” command that is shown further down in one of the examples.

While this may be obvious, it is worth repeating again: Since we are taking hotbackup, the Oracle database can be up and running. Make sure your Oracle database is running before you execute any of the above RMAN backup commands.

4. Assign Backup TAG Name for Quick Identification

If you are taking lot of backups, it will be easier to assign a tag to a particular backup, which we’ll later use during Oracle recovery (or while using list command to view it).

The following example assign a backup tag called “WEEEKLY_PRD01_TBLS_BK_ONLY” to this particular backup.

RMAN> BACKUP AS BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;
Starting backup at 10-AUG-13
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00002 name=/u03/oradata/devdb/PRD01_1.dbf
channel ORA_DISK_1: starting piece 1 at 10-AUG-13
channel ORA_DISK_1: finished piece 1 at 10-AUG-13
piece handle=/backup/rman/full_4fogpdb3_4239_1 tag=WEEEKLY_PRD01_TBLS_BK_ONLY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 10-AUG-13
Starting Control File and SPFILE Autobackup at 10-AUG-13
piece handle=/backup/rman/ctl_c-758818131-20130808-01 comment=NONE
Finished Control File and SPFILE Autobackup at 10-AUG-13

Once the backup is finished, if you view the files from rman directory, you’ll not see the tag name here. Tag name is used only from RMAN repositories to view and restore backups. So, now you see there are more files in this directory, as we’ve taken couple of backups.

$ ls -l /backup/rman/
total 29176
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1

 

5. Change Oracle RMAN Backup File Name Format

If you want the backup files itself will be in a specific format, you need to change the format in the RMAN configuration as shown below. In this example, we’ve appended the tag “full_devdb_bk_” prefix to all our backup files.

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   "/backup/rman/full_devdb_bk_%u_%s_%p" MAXPIECESIZE 2048 M;

Now, let us take another backup with this modified configuration.

RMAN> BACKUP AS BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;

Now when you view the RMAN files, you’ll see the new RMAN backup file has this new file name format for the files. This is easier to identify certain information about the backup just by looking at the file names.

$ ls -l /backup/rman/
total 43764
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba 14585856 Aug  8 11:56 ctl_c-758818131-20130808-02
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:55 full_devdb_bk_4hogpdef_4241_1

 

6. Compress a RMAN Backup

If you are taking a backup of a big database, you’ll notice that the RMAN backup files are bigger (almost same size as the database itself).

So, for most situation, you should always tak ea compressed backup of the database.

The following example take a compressed backup of the tablepsace PRD01.

RMAN> BACKUP AS COMPRESSED BACKUPSET TAG 'WEEEKLY_PRD01_TBLS_BK_ONLY' TABLESPACE PRD01;

When you view the backup files from the file system level, you will not see any .gz (or .zip, or .bz2) to indicate that the RMAN has taken a compressed backup. The file naming convention will still follow the same as a non-compressed backup.

$ ls -l /backup/rman/
total 58352
-rw-r----- 1 oracle dba 14585856 Aug  8 11:48 ctl_c-758818131-20130808-00
-rw-r----- 1 oracle dba 14585856 Aug  8 11:54 ctl_c-758818131-20130808-01
-rw-r----- 1 oracle dba 14585856 Aug  8 11:56 ctl_c-758818131-20130808-02
-rw-r----- 1 oracle dba 14585856 Aug  8 11:59 ctl_c-758818131-20130808-03
-rw-r----- 1 oracle dba   327680 Aug  8 11:48 full_4dogpd0u_4237_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:54 full_4fogpdb3_4239_1
-rw-r----- 1 oracle dba   327680 Aug  8 11:55 full_devdb_bk_4hogpdef_4241_1
-rw-r----- 1 oracle dba   127680 Aug  8 11:59 full_devdb_bk_4jogpdl0_4243_1

Note: The way to tell whether RMAN has take a compressed backup or not, it by looking at the size, and by looking at the output of the RMAN “list” command which is shown in one of the section below.

7. View all RMAN Backups

To view all the RMAN backups, execute “list backup summary” as shown below.

RMAN> LIST BACKUP SUMMARY;

using target database control file instead of recovery catalog

List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
..
4215    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T114846
4216    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T114849
4217    B  F  A DISK        10-AUG-13       1       1       NO         WEEEKLY_PRD01_TBLS_BK_ONLY
4218    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T115413
4219    B  F  A DISK        10-AUG-13       1       1       NO         WEEEKLY_PRD01_TBLS_BK_ONLY
4220    B  F  A DISK        10-AUG-13       1       1       NO         TAG20130808T115600
4221    B  F  A DISK        10-AUG-13       1       1       YES        WEEEKLY_PRD01_TBLS_BK_ONLY

As you see above, it displays various information about the backups. In the above output, it show 7 RMAN backups. The last column shows the “Tag” that we specified when we took a backup. If we didn’t specify any TAG, RMAN creates a default tag with the prefix “TAG” followed by some numbers. You can also see that under the column “Compressed”, the last RMAN backup shows “YES”, which indicates that out of all the 7 RMAN backups, only the last one was compressed.

Also, when the RMAN backup is running, if you want to see the proress, you can query the V$RMAN_STATUS table from sql*plus as shown below.

SQL> SELECT OPERATION, STATUS, MBYTES_PROCESSED, START_TIME, END_TIME from V$RMAN_STATUS;

OPERATION                         STATUS                  MBYTES_PROCESSED START_TIM END_TIME
--------------------------------- ----------------------- ---------------- --------- ---------
CONTROL FILE AND SPFILE AUTOBACK  COMPLETED                             14 07-NOV-12 07-NOV-12
RMAN                              COMPLETED                              0 07-NOV-12 07-NOV-12
RESTORE VALIDATE                  COMPLETED                              0 07-NOV-12 07-NOV-12
RMAN                              COMPLETED WITH ERRORS                  0 07-NOV-12 07-NOV-12
DELETE                            COMPLETED                              0 08-NOV-12 08-NOV-12
BACKUP                            COMPLETED                              0 10-AUG-13 10-AUG-13
CONTROL FILE AND SPFILE AUTOBACK  COMPLETED                             14 10-AUG-13 10-AUG-13
RMAN                              COMPLETED WITH ERRORS               1832 10-AUG-13 10-AUG-13
RMAN                              COMPLETED                              0 10-AUG-13 10-AUG-13
...

There you have it.
That is how you take an Oracle RMAN backup.

Share

How to transfer data from your old iPhone to your new iPhone

June 12th, 2017, posted in Apple
Share

How to transfer your data to your new iPhone using iTunes

Here’s the deal: If you make an encrypted backup of your old iPhone using iTunes, then restore it to your new iPhone, it’ll bring most — if not all — your password information along with it. That’ll save you a lot of time and effort getting set back up.

You do need a Lightning to USB cable (or 30-pin Dock to USB if you have an iPhone 4s or earlier), and you’ll still have to re-download apps — the App Store gives you slightly different versions for each device, optimized to run best on that specific hardware — but overall I still find it to be much, much faster.

  1. Make sure you’re running the most recent version of iTunes.
  2. Plug your old iPhone into your Mac or Windows PC.
  3. Launch iTunes.
  4. Click on the iPhone icon in the menu bar when it appears.
  5. Click on Back Up Now.
  6. Click on Encrypt Backup and add a password.
  7. Skip Backup Apps, if asked. (They’ll likely re-download anyway.)
  8. Unplug your old iPhone when done.
  9. Turn off your old iPhone.
  10. On iTunes on your Mac or Windows PC, select Restore from this backup.
  11. Choose your recent backup from the list.
  12. Enter your password if your backup was encrypted and it asks.
  13. Take your SIM card out of your old iPhone. (If you don’t have a new or separate SIM card for your new phone.)How to transfer data from your old iPhone to your new iPhone ,How to transfer data from your old iPhone, new iPhone,iPhone,How to transfer data,iTunes,most recent version of iTunes.Wait for the backup to complete before proceeding.
    1. Put your SIM card into your new iPhone. (If it didn’t come with a new or different SIM card.)
    2. Turn on your new iPhone.
    3. Plug your new iPhone into your Mac or Windows PC.
    4. Slide to set up on your iPhone.
    5. Follow the directions to choose your language and set up your Wi-Fi network.
    6. Select Restore from iTunes backup.
      How to transfer data from your old iPhone to your new iPhone ,How to transfer data from your old iPhone, new iPhone,iPhone,How to transfer data,iTunes,most recent version of iTunes.
    7. On iTunes on your Mac or Windows PC, select Restore from this backup.
    8. Choose your recent backup from the list.
    9. Enter your password if your backup was encrypted and it asks.How to transfer data from your old iPhone to your new iPhone ,How to transfer data from your old iPhone, new iPhone,iPhone,How to transfer data,iTunes,most recent version of iTunes.



      Keep your iPhone plugged into iTunes until the transfer is complete, and on Wi-Fi until all re-downloads are complete. Depending on how much data you have to re-download, including music and apps, it might take a while.Your iPhone might feel warm or even hot, and you might burn a lot of battery life for the first few hours or even a day or due to the radios working and the Spotlight search system indexing. Just let it finish.
Share

How to Back Up or Copy Your Outlook Mail, Contacts and Other Data

April 7th, 2014, posted in Windows
Share


How to Back Up or Copy Your Outlook Mail, Contacts and Other Data

This is a very good link with all the steps to make Back Up or Copy Your Outlook Mail, Contacts and Other Data :

http://www.makeuseof.com/tag/5-easy-ways-to-back-up-your-microsoft-outlook-data/




Share

Oracle : Seven Deadly Habits Of A DBA And How To Cure Them

June 20th, 2013, posted in Oracle
Share

Seven Deadly Habits Of A DBA And How To Cure Them,oracle,dba,cure,sin,mistake,issues,Seven Deadly Habits of a DBA and how to cure them

Calling widespread bad habits in database administration “deadly” may seem extreme. However, when you consider the critical nature of most data, and just how damaging data loss or corruption can be to a corporation, “deadly” seems pretty dead-on.
Although these habits are distressingly common among DBAs, they are curable with some shrewd management intervention. What follows is a list of the seven habits we consider the deadliest, along with some ideas on how to eliminate them.

Habit #1. THE LEAP OF FAITH: “We have faith in our backup.”
Blind faith can be endearing, but not when it comes backing up a database. Backups should be trusted only as far as they have been tested and verified.
Cures:

  • Have your DBAs verify that the backup is succeeding regularly, preferably using a script that notifies them if there’s an issue.
  • Maintain a backup to your backup. DBAs should always use at least two backup methods. A common technique is to use those old-fashioned exports as a backup to the online backups.
  • Resource test recoveries as often as is practical. An early sign that your DBA team is either overworked or not prioritizing correctly is having a quarter go by without a test recovery. Test recoveries confirm that your backup strategy is on track, while allowing your team to practice recovery activities so they can handle them effectively when the time comes.

Habit #2. GREAT EXPECTATIONS: “It will work the way we expect it to. Let’s go ahead.”
Although not user friendly in the traditional sense, Oracle is very power-user friendly— once you’ve been working with it for a while, you develop an instinct for the way things “should” work. Although that instinct is often right, one of the most dangerous habits any DBA can possess is an assumption that Oracle will “just work” the way it should.
Cures:

  • Inculcate a “practice, practice, practice” mentality throughout the organization. DBAs need to rehearse activities in the safe sandbox of a test environment that’s designed to closely mimic the behaviour of the production system. The organization needs to allow the time and money for them to do so.
  • Pair inexperienced DBAs with senior ones whenever possible—or take them under your own wing. New DBAs tend to be fearless, but learning from someone else’s experience can help instill some much needed paranoia.
  • Review the plans for everything. It’s amazing how often DBAs say, “I’ve done that a hundred times, I don’t need a plan.” If they’re heading into execution mode, they absolutely need a plan.

Habit #3. LAISSEZ-FAIRE ADMINISTRATION: “We don’t need to monitor the system. The users always let us know when something’s wrong.”
If you depend on the users to inform the DBA team that there’s a problem, it may already be too late.
Cures:

  • Install availability and performance monitoring systems so that issues are identified and resolved before they cause service-affecting failures.
  • Avoid post-release software issues by working with developers and testers to ensure that all production-ready software is stable and high-performance.

Habit #4. THE MEMORY TEST: “We’ll remember how this happened, and what we did to get things going again.”

It may seem impossible that a DBA team would forget a massive procedure that took them weeks to get right, and yet it happens all the time. In order to prevent recurring mistakes and take advantage of gained experience, documentation is essential.

Cures:

  • Require that your DBAs maintain a comprehensive documentation library and activity diary, including a significant level of rationale, syntax, and workflow detail.
  • Provide your team with groupware on your intranet so that these documents become searchable in an emergency.
  • Enforce the discipline of documentation and check it periodically. Ask your DBAs: When was this tablespace created, by whom, and with what SQL? What tasks were performed on a particular day? If they can’t answer quickly, you’ll know they’ve gone back to relying on memory.

Habit #5. THE BLAME GAME: “Don’t look at me, it’s the developer’s fault that SQL is in production”

Some DBAs have a real “us versus them” mentality when it comes to developers in their organization. They see themselves not as facilitators helping the developers develop quality code from a database standpoint, but rather as guardians who prevent poor-quality code from making it into production. This might seem like semantics, but a confrontational relationship between developers and DBAs results in a lack of developer initiative and significant slowdowns in release cycles.

Cures:

  • Select DBAs who understand it’s their responsibility to work as an integrated team with the developers they support.
  • Cultivate a team attitude by structuring continuous DBA involvement in every project rather than at review milestones.
  • Consider assigning an individual DBA in a developer support role. If it’s clearly in the job description, there’s more motivation to do it well.

Habit #6. THE SOLO ACT: “I know what I’m doing and don’t need any help.”

Database administration is increasingly complex and even the most senior DBAs can’t possibly know every last detail. DBAs have different specialties, which need to be culled and utilized. When DBAs feel like they know, or should know, everything, they don’t ask questions and miss out on valuable knowledge they could be gaining from others.
Cures:

  • Foster a teamwork culture where it’s acceptable for DBAs to admit they don’t know the answer and to ask for help.
  • Encourage your DBAs to seek out an outside peer group as a forum for brainstorming and testing their assumptions. No single person can match the expertise and experience of even a relatively small group.
  • Provide a safety net of tech resources such as reference materials, courses, and outside experts or consultants on call.

Habit #7. TECHNO-LUST: “Things would work so much better if only we had…”
DBAs are often on top of the latest technology, which can help them do a superlative job. But when the desire for new technology causes DBAs to recommend unnecessary hardware purchases or software add-ons, costs tend to skyrocket quickly—as do problems.

Cures:

  • Never upgrade your hardware infrastructure without first exhausting all tuning opportunities. Remember, ten years ago enormous enterprises were run on servers one-tenth the capacity—all thanks to necessity and skill.
  • Never consent to using advanced or new features until you’re well aware of the ongoing maintenance commitment and resulting costs.
  • Watch out for DBA support software that presents friendly GUI interfaces for difficult tasks. This type of interface allows a beginner DBA to act as an intermediate DBA under certain circumstances, but simultaneously prevents that beginner from learning the actual skills behind the tasks. Moreover, these tools tend to hide real risks from the DBA, making potentially damaging activities as easy as point-and-click.Whether it takes a twelve-step program or one tiny adjustment, all of these deadly DBA habits can be kicked. Of course, the first step is recognizing the problem. By starting with this list and doing a careful inventory of the successes and failures in your team’s database administration, you’ll be well on your way to finding a cure
Main url: http://appsdbaclass.blogspot.com/2011/10/seven-deadly-habits-of-dbaand-how-to.html?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+OracleAppsDbaoracleEbsR12+%28Oracle+Apps+DBA+%28Oracle+EBS+R12%29%29
Share