Dba Interview Questions & Answers
Dba Interview Questions & Answers
IMAGE COPY
THE ADVANTAGE OF UING IMAGE COPY IS ITS NOT IN RMAN PROPRIETARY
FORMAT..
BACKUP FORMAT
RMAN BACKUP IS NOT IN ORACLE FORMAT BUT IN RMAN FORMAT. ORACLE
BACKUP COMPRISES OF BACKUP SETS AND IT CONSISTS OF BACKUP PIECES.
BACKUP SETS ARE LOGICAL ENTITY IN ORACLE 9I IT GETS STORED IN A
DEFAULT LOCATION THERE ARE TWO TYPE OF BACKUP SETS DATAFILE
BACKUP SETS, ARCHIVELOG BACKUP SETS ONE MORE IMPORTANT POINT OF
DATA FILE BACKUP SETS IS IT DO NOT INCLUDE EMPTY BLOCKS. A BACKUP
SET WOULD CONTAIN MANY BACKUP PIECES.
A SINGLE BACKUP PIECE CONSISTS OF PHYSICAL FILES WHICH ARE IN RMAN
PROPRIETARY FORMAT.
RESTORING DATABASE
RESTORING DATABASE HAS BEEN MADE VERY SIMPLE IN 9I .
IT IS JUST RESTORE DATABASE..
RMAN HAS BECOME INTELLIGENT TO IDENTIFY WHICH DATAFILES HAS TO BE
RESTORED
AND THE LOCATION OF BACKUPED UP FILE.
WITH THE NEW DURATION OPTION FOR THE RMAN BACKUP COMMAND, DBAS
CAN WEIGH BACKUP PERFORMANCE AGAINST SYSTEM SERVICE LEVEL
REQUIREMENTS. BY SPECIFYING A DURATION, RMAN WILL AUTOMATICALLY
CALCULATE THE APPROPRIATE BACKUP RATE; IN ADDITION, DBAS CAN
OPTIONALLY SPECIFY WHETHER BACKUPS SHOULD MINIMIZE TIME OR
SYSTEM LOAD.
NEW FEATURES IN OEM TO IDENTIFY RMAN RELATED BACKUP LIKE BACKUP
PIECES, BACKUP SETS AND IMAGE COPY
OBSERVATION :-
INTRODUCED IN ORACLE 8 IT HAS BECOME MORE POWERFUL AND SIMPLER
WITH NEWER VERSION OF ORACLE 9 AND 10 G. SO IF YOU REALLY DON'T
WANT TO MISS SOMETHING CRITICAL PLEASE START USING RMAN.
Backup and recovery is one of the most important aspects of a DBA's job. If you lose your
company's data, you could very well lose your job. Hardware and software can always be
replaced, but your data may be irreplaceable!
Normally one would schedule a hierarchy of daily, weekly and monthly backups, however
consult with your users before deciding on a backup schedule. Backup frequency normally
depends on the following factors:
Carefully plan backup retention periods. Ensure enough backup media (tapes) are available
and that old backups are expired in-time to make media available for new backups. Off-site
vaulting is also highly recommended.
Frequently test your ability to recover and document all possible scenarios. Remember, it's
the little things that will get you. Most failed recoveries are a result of organizational errors
and miscommunication.
* Cold or Off-line Backups - shut the database down and backup up ALL data, log, and
control files.
* Hot or On-line Backups - If the database is available and in ARCHIVELOG mode, set
the tablespaces into backup mode and backup their files. Also remember to backup the
control files and archived redo log files.
* RMAN Backups - while the database is off-line or on-line, use the "rman" utility to
backup the database.
It is advisable to use more than one of these methods to backup your database. For
example, if you choose to do on-line database backups, also cover yourself by doing
database exports. Also test ALL backup and recovery scenarios carefully. It is better to be
safe than sorry.
Regardless of your strategy, also remember to backup all required software libraries,
parameter files, password files, etc. If your database is in ARCHIVELOG mode, you also
need to backup archived log files.
A hot (or on-line) backup is a backup performed while the database is open and available
for use (read and write activity). Except for Oracle exports, one can only do on-line backups
when the database is ARCHIVELOG mode.
A cold (or off-line) backup is a backup performed while the database is off-line and
unavailable to its users. Cold backups can be taken regardless if the database is in
ARCHIVELOG or NOARCHIVELOG mode.
It is easier to restore from off-line backups as no recovery (from archived logs) would be
required to make the database consistent. Nevertheless, on-line backups are less disruptive
and don't require database downtime.
RMAN> run {
set until time to_date('04-Aug-2004 00:00:00', 'DD-MON-YYYY HH24:MI:SS');
restore database;
recover database;
}
Nevertheless, Oracle Consulting can sometimes extract data from an offline database using
a utility called DUL (Disk UnLoad - Life is DUL without it!). This utility reads data in the data
files and unloads it into SQL*Loader or export dump files. Hopefully you'll then be able to
load the data into a working database.
Note that DUL does not care about rollback segments, corrupted blocks, etc, and can thus
not guarantee that the data is not logically corrupt. It is intended as an absolute last resort
and will most likely cost your company a lot of money!
DUDE (Database Unloading by Data Extraction) is another non-Oracle utility that can be
used to extract data from a dead database.
One of the advantages of exports is that one can selectively re-import tables, however one
cannot roll-forward from an restored export. To completely restore a database from an
export file one practically needs to recreate the entire database.
Always do full system level exports (FULL=YES). Full exports include more information
about the database in the export file than user level exports. For more information about
the Oracle export and import utilities, see the Import/ Export FAQ.
Alternatively, add the above commands into your database's startup command script, and
bounce the database.
log_archive_start = TRUE
log_archive_dest_1 = 'LOCATION=/arch_dir_name'
log_archive_dest_state_1 = ENABLE
log_archive_format = %d_%t_%s.arc
NOTE 1: Remember to take a baseline database backup right after enabling archivelog
mode. Without it one would not be able to recover. Also, implement an archivelog backup
to prevent the archive log directory from filling-up.
NOTE 2:' ARCHIVELOG mode was introduced with Oracle 6, and is essential for database
point-in-time recovery. Archiving can be used in combination with on-line and off-line
database backups.
NOTE 3: You may want to set the following INIT.ORA parameters when enabling
ARCHIVELOG mode: log_archive_start=TRUE, log_archive_dest=..., and
log_archive_format=...
NOTE 4: You can change the archive log destination of a database on-line with the
ARCHIVE LOG START TO 'directory'; statement. This statement is often used to switch
archiving between a set of directories.
NOTE 5: When running Oracle Real Application Clusters (RAC), you need to shut down all
nodes before changing the database to ARCHIVELOG mode. See the RAC FAQ for more
details.
[edit] I've lost an archived/online REDO LOG file, can I get my DB back?
The following INIT.ORA/SPFILE parameter can be used if your current redologs are
corrupted or blown away. It may also be handy if you do database recovery and one of the
archived log files are missing and cannot be restored.
NOTE: Caution is advised when enabling this parameter as you might end-up losing your
entire database. Please contact Oracle Support before using it.
_allow_resetlogs_corruption = true
This should allow you to open the database. However, after using this parameter your
database will be inconsistent (some committed transactions may be lost or partially
applied).
Steps:
Shut down the database from sqlplus or server manager. Backup all files to secondary
storage (eg. tapes). Ensure that you backup all data files, all control files and all log files.
When completed, restart your database.
Do the following queries to get a list of all files that needs to be backed up:
Sometimes Oracle takes forever to shutdown with the "immediate" option. As workaround
to this problem, shutdown using these commands:
Each tablespace that needs to be backed-up must be switched into backup mode before
copying the files out to secondary storage (tapes). Look at this simple example.
It is better to backup tablespace for tablespace than to put all tablespaces in backup mode.
Backing them up separately incurs less overhead. When done, remember to backup your
control files. Look at this example:
ALTER SYSTEM SWITCH LOGFILE; -- Force log switch to update control file
headers
ALTER DATABASE BACKUP CONTROLFILE TO '/backupDir/control.dbf';
NOTE: Do not run on-line backups during peak processing periods. Oracle will write
complete database blocks instead of the normal deltas to redo log files while in backup
mode. This will lead to excessive database archiving and even database freezes.
One can select from V$BACKUP to see which datafiles are in backup mode. This normally
saves a significant amount of database down time. See script end_backup2.sql in the
Scripts section of this site.
From Oracle9i onwards, the following command can be used to take all of the datafiles out
of hotbackup mode:
This command must be issued when the database is mounted, but not yet opened.
4.Does Oracle write to data files in begin/hot backup mode?
When a tablespace is in backup mode, Oracle will stop updating its file headers, but will
continue to write to the data files.
When in backup mode, Oracle will write complete changed blocks to the redo log files.
Normally only deltas (change vectors) are logged to the redo logs. This is done to enable
reconstruction of a block if only half of it was backed up (split blocks). Because of this, one
should notice increased log activity and archiving during on-line backups.
Recovery Manager (or RMAN) is an Oracle provided utility for backing-up, restoring and
recovering Oracle Databases. RMAN ships with the database server and doesn't require a
separate installation. The RMAN executable is located in your ORACLE_HOME/bin directory.
In fact RMAN, is just a Pro*C application that translates commands to a PL/SQL interface.
The PL/SQL calls are stallically linked into the Oracle kernel, and does not require the
database to be opened (mapped from the ?/rdbms/admin/recover.bsq file).
RMAN can do off-line and on-line database backups. It cannot, however, write directly to
tape, but various 3rd-party tools (like Veritas, Omiback, etc) can integrate with RMAN to
handle tape library management.
RMAN can be operated from Oracle Enterprise Manager, or from command line. Here are
the command line arguments:
Argument Value Description
-----------------------------------------------------------------------------
target quoted-string connect-string for target database
catalog quoted-string connect-string for recovery catalog
nocatalog none if specified, then no recovery catalog
cmdfile quoted-string name of input command file
log quoted-string name of output message log file
trace quoted-string name of output debugging message log file
append none if specified, log is opened in append mode
debug optional-args activate debugging
msgno none show RMAN-nnnn prefix for all messages
send quoted-string send a command to the media manager
pipe string building block for pipe names
timeout integer number of seconds to wait for pipe input
-----------------------------------------------------------------------------
Here is an example:
The biggest advantage of RMAN is that it only backup used space in the database. RMAN
doesn't put tablespaces in backup mode, saving on redo generation overhead. RMAN will
re-read database blocks until it gets a consistent image of it. Look at this simple backup
example.
The examples above are extremely simplistic and only useful for illustrating basic concepts.
By default Oracle uses the database controlfiles to store information about backups.
Normally one would rather setup a RMAN catalog database to store RMAN metadata in.
Read the Oracle Backup and Recovery Guide before implementing any RMAN backups.
Note: RMAN cannot write image copies directly to tape. One needs to use a third-party
media manager that integrates with RMAN to backup directly to tape. Alternatively one can
backup to disk and then manually copy the backups to tape.
One can backup archived log files using RMAN or any operating system backup utility.
Remember to delete files after backing them up to prevent the archive log directory from
filling up. If the archive log directory becomes full, your database will hang! Look at this
simple RMAN backup scripts:
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> format '/app/oracle/archback/log_%t_%sp%p'
5> (archivelog all delete input);
6> release channel dev1;
7> }
The "delete input" clause will delete the archived logs as they are backed-up.
RMAN> run {
2> allocate channel dev1 type disk;
3> restore (archivelog low logseq 78311 high logseq 78340 thread 1 all);
4> release channel dev1;
5> }
sqlplus sys
SQL> create user rman identified by rman;
SQL> alter user rman default tablespace tools temporary tablespace temp;
SQL> alter user rman quota unlimited on tools;
SQL> grant connect, resource, recovery_catalog_owner to rman;
SQL> exit;
Next, log in to rman and create the catalog schema. Prior to Oracle 8i this was done by
running the catrman.sql script.
You can now continue by registering your databases in the catalog. Look at this example:
One can also use the "upgrade catalog;" command to upgrade to a new RMAN release, or
the "drop catalog;" command to remove an RMAN catalog. These commands need to be
entered twice to confirm the operation.
The following Media Management Software Vendors have integrated their media
management software with RMAN (Oracle Recovery Manager):
The above Media Management Vendors will provide first line technical support (and
installation guides) for their respective products.
When allocating channels one can specify Media Management spesific parameters. Here are
some examples:
Netbackup on Solaris:
allocate channel t1 type
'SBT_TAPE' PARMS='SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1';
Netbackup on Windows:
or:
The first step to clone or duplicate a database with RMAN is to create a new INIT.ORA and
password file (use the orapwd utility) on the machine you need to clone the database to.
Review all parameters and make the required changed. For example, set the DB_NAME
parameter to the new database's name.
Secondly, you need to change your environment variables, and do a STARTUP NOMOUNT
from sqlplus. This database is referred to as the AUXILIARY in the script below.
Lastly, write a RMAN script like this to do the cloning, and call it with "rman cmdfile
dupdb.rcv":
run {
set newname for datafile 1 to '/ORADATA/u01/system01.dbf';
set newname for datafile 2 to '/ORADATA/u02/undotbs01.dbf';
set newname for datafile 3 to '/ORADATA/u03/users01.dbf';
set newname for datafile 4 to '/ORADATA/u03/indx01.dbf';
set newname for datafile 5 to '/ORADATA/u02/example01.dbf';
The above script will connect to the "target" (database that will be cloned), the recovery
catalog (to get backup info), and the auxiliary database (new duplicate DB). Previous
backups will be restored and the database recovered to the "set until time" specified in the
script.
Notes: the "set newname" commands are only required if your datafile names will different
from the target database.
Details of RMAN backups are stored in the database control files and optionally a Recovery
Catalog. If both these are gone, RMAN cannot restore the database. In such a situation one
must extract a control file (or other files) from the backup pieces written out when the last
backup was taken. Let's look at an example:
Now, let's see if we can restore it. First we need to start the databaase in
NOMOUNT mode:
Now, from SQL*Plus, run the following PL/SQL block to restore the file:
DECLARE
v_devtype VARCHAR2(100);
v_done BOOLEAN;
v_maxPieces NUMBER;
-- Allocate a channel... (Use type=>null for DISK, type=>'sbt_tape' for TAPE)
v_devtype := DBMS_BACKUP_RESTORE.deviceAllocate(type=>NULL, ident=>'d1');
-- CFNAME mist be the exact path and filename of a controlfile taht was backed-up
DBMS_BACKUP_RESTORE.restoreControlFileTo(cfname=>'/app/oracle/oradata/orcl/contro
l01.ctl');
SQL> ! ls -l /oradata/orcl/control01.ctl
-rw-r----- 1 oracle dba 3096576 Aug 20 16:45 /oradata/orcl/control01.ctl[/code]
Database altered.
Database altered.
1. Explain the difference between a hot backup and a cold backup and the benefits
associated with each.?
A hot backup is basically taking a backup of the database while it is still up and running and
it must be in archive log mode. A cold backup is taking a backup of the database while it is
shut down and does not require being in archive log mode. The benefit of taking a hot
backup is that the database is still available for use while the backup is occurring and you
can recover the database to any point in time. The benefit of taking a cold backup is that it
is typically easier to administer the backup and recovery process. In addition, since you are
taking cold backups the database does not require being in archive log mode and thus
there will be a slight performance gain as the database is not cutting archive logs to disk.
2. You have just had to restore from backup and do not have any control files. How would
you go about bringing up this database?
I would create a text based backup control file, stipulating where on disk all the data files
where and then issue the recover command with the using backup control file clause.
3. How do you switch from an init.ora file to a spfile?
Issue the create spfile from pfile command.
4. Explain the difference between a data block, an extent and a segment.?
A data block is the smallest unit of logical storage for a database object. As objects grow
they take chunks of additional storage that are composed of contiguous data blocks. These
groupings of contiguous data blocks are called extents. All the extents that an object takes
when grouped together are considered the segment of the database object.
5. Give two examples of how you might determine the structure of the table DEPT.?
Use the describe command or use the dbms_metadata.get_ddl package.
6. Where would you look for errors from the database engine?
In the alert log.
7. Compare and contrast TRUNCATE and DELETE for a table.?
Both the truncate and delete command have the desired outcome of getting rid of all the
rows in a table. The difference between the two is that the truncate command is a DDL
operation and just moves the high water mark and produces a now rollback. The delete
command, on the other hand, is a DML operation, which will produce a rollback and thus
take longer to complete.
9. Give the two types of tables involved in producing a star schema and the type of data
they hold.?
Fact tables and dimension tables. A fact table contains measurements while dimension
tables will contain data that will help describe the fact tables.
1