Oracle Database Administration for Microsoft SQL Server DBAs part 15 pps

locations that can be centrally managed. All that is required on the client
side is the information for the Oracle Internet Directory. For the connection
to the Oracle Internet Directory to look up the location of the database, an
ldap.ora file is needed in the ORACLE_HOME/network/admin directory.
Here is an example of an ldap.ora file:
DEFAULT_ADMIN_CONTEXT = "ou=databases,dc=company1,dc=com"
DIRECTORY_SERVICES = (ldap_server.company1.com:389:636)
DIRECTORY_SERVER_TYPE = OID
The sqlnet.ora file has parameters for using the Oracle Internet Directory,
tnsnames.ora, EZCONNECT (easy connection naming method without
tnsnames.ora), and the default domain. There is also expiration time of the
client connection, and this can be used to trace client sessions. Here is a list
of some of these parameters in a sample sqlnet.ora:
NAMES.DEFAULT_DOMAIN = (US.COM)
###It will try these connections in this order path first
### LDAP, etc.
NAMES.DIRECTORY_PATH = (LDAP, TNSNAMES, EZCONNECT)
## NTS allows oracle to use current Windows domain credentials to
## authenticate. If Oracle server is not configured for this, errors will
## occur in connecting.But setting NONE first will only disable the local
## support using Windows credentials
SQLNET.AUTHENTICATION_SERVICES = (NONE,NTS)
##These parameters can be uncommented to start the tracing
##TRACE_LEVEL_CLIENT=4
##TRACE_FILE_CLIENT=client_sqlnet.trc
##TRACE_DIRECTORY_CLEINT=D:\oracle\trace
## Time is specified in minutes for the expire time but this
## would be set on the database server
SQLNET.EXPIRE_TIME=30
As seen with the NTS setting in this file, the Windows domain credentials
would be useful for defining externally authenticated users in the database,

and then setting AUTHENTICATION_SERVICES = ( NTS) will allow for
passing the Windows credentials through to the database. Since the sqlnet.ora
file is on both the client and server side, there might be some parameters
that are set for the server, but these may still have an effect on the client.
For example, EXPIRE_TIME will time out sessions.
122
Oracle Database Administration for Microsoft SQL Server DBAs
The most common issues when setting up a connection to the database
stem from incorrect information in the connection string, tnsnames.ora file,
or sqlnet.ora file. I have even tried to track down a connection issue, only to
discover that there were two different tnsnames.ora files, and the one with
the incorrect information was being looked at first because it came up first
in the path environment variable.
As you’ve seen, the sqlnet.ora file also has information on authentication
and the domain. If this doesn’t match up with your environment, it might
be looking for a database in a different domain, or even looking for a
tnsnames.ora file when it is set up to use LDAP.
These files can be edited manually, but typing issues may cause trouble
if the files were generated by an Oracle configuration tool.
It is also possible that TNS errors will come up if you are logging in
to SQL*Plus and the ORACLE_SID variable is not set or you are using
usernameORACLE_SID to define which database the client is attempting
to connect to.
JDBC Connections
The applications and clients normally set up the connections, and the
details of the host, database name, and port should be all that they need to
get started. However, they may sometimes need assistance with connections
and using different drivers.
For JDBC drivers, there are thin and thick clients. There is not much
difference between the two, except that the thick client has the ability to use

the tnsnames.ora file, and the thin client might not have these structures set
up because just the drivers were installed.
url="jdbc:oracle:thin:host:port:sid"
url="jdbc:oracle:thin:(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=orasrvrac1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=orasrvrac2-vip)(PORT=1521))
(COONECT_DATA=(SERVICE_NAME=RACDB)))"
## thick client can use the database name in the tnsnames.ora file
url="jdbc:oracle:orci:MMDEV1"
Aliases
A SQL Server instance can have an alias to use a client network utility. Even
a local instance with no name can get a different name to use as an alias.
Chapter 5: DBA Tools
123
The same is true for Oracle databases. A database alias can be set up in the
tnsnames.ora file.
DB_ALIAS =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraserver1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = MMDEV1)
)
)
In this example, DB_ALIAS will actually connect to the MMDEV1 database.
It is that simple to create an alias, and it obviously doesn’t change the actual
name of the database.
CAUTION
In the tnsnames.ora file, having the same name

listed twice can cause connection issues. Even
if the details are the same for both of the
listings, duplicates can cause problems
connecting.
My Oracle Support
Most of these tools discussed in this chapter are used on a daily basis to
manage the database and log in to databases. I consider My Oracle Support
a tool, because not only does it have a knowledge base for commands,
issues, and possible errors, but it also has the Configuration Manager for
assistance in applying patches and upgrades. It also offers a health check
monitor that provides some suggestions based on the configurations in the
databases.
There is community out there, and through My Oracle Support, you can
have discussions with other DBAs. In addition to those you can find through
the message areas in My Oracle Support, other Oracle user communities are
great resources for information and networking. User groups such as the
Independent Oracle User Group (IOUG) have real DBAs performing real
tasks, and they are willing to share their experiences and help you to work
through issues.
124
Oracle Database Administration for Microsoft SQL Server DBAs
Summary
In this chapter, we have discussed several different tools available to Oracle
DBAs. Some of the tools are geared more toward the management of the
database servers; others might be more focused on development. Both types
are useful for DBAs. There are several areas to explore in OEM and SQL
Developer to make you more productive as a DBA. And don’t forget that
even though it is good to have an easy interface to use, it’s also handy to be
able to run simple scripts and queries in a regular SQL*Plus session.
However, it’s not too useful to have these tools if you cannot connect

them to the database. So, we discussed how to get connected and took a
look at the pieces that are needed to connect, including the tnsnames.ora
and sqlnet.ora files.
Chapter 5: DBA Tools
125
This page intentionally left blank
CHAPTER
6
Database Backup,
Restore, and
Recovery
A
s a DBA, you already know the importance of database
backups. You have probably developed your own backup
strategies and disaster recovery plans for the SQL Server
databases you support.
You also know that being able to back up a database is just part of the
job. You need to manage the backups and know which backup pieces to
use to be able to recover quickly and easily. Testing restore procedures
validates that you have solid, usable backups, and also lets you develop
restore scripts to save for a rainy day.
In this chapter, you will learn about the set of backup and recovery tools
available for the Oracle platform. This will help you to develop your backup
and recovery strategies for your Oracle databases.
Backing Up Databases
Sometimes your job as a DBA may seem like all you are doing is verifying
that backups are running successfully and restoring testing environments
with those backups. This is definitely an important task for the system DBA,
and backups are key to providing a secure and reliable database environment.
Backup Strategies

As a DBA, no matter which database platform you are administering, you
need to plan a backup strategy that makes recovery a simple process and fits
the needs of the business. There are several strategies for backing up databases,
depending on resources, the importance of the data, and if it is needed for
recovery and running the business.
For SQL Server databases, creating maintenance plans sets up some
backup strategies. The SQL Server database recovery model setting of either
SIMPLE or FULL also determines if log backups are needed. As the database
changes or grows, plans to compress, write to tape, and allocate threads to
use for the backup are all taken into consideration.
The Oracle DBCA also has a step to set up maintenance plans, which
include backup settings. You also have the option to create the database in
NOARCHIVELOG mode, which is similar to the SQL Server SIMPLE option,
or ARCHIVELOG mode, which is like the FULL option.
128
Oracle Database Administration for Microsoft SQL Server DBAs
It is important to be able to communicate the options for backup and
restore strategies to the business owners. Understanding the options, the
resources needed (disks, tapes, and so on), and what data loss would mean
to the business are key to being able to convey how the restore options
would benefit the business. This will help you and the business owners to
develop the best plan to balance the resources and protect the data assets.
What are you protecting against? You probably have been setting up
backup strategies to protect against hardware failures, data loss, changes
that have gone wrong, and disasters. Running backup database and
transaction logs, and saving copies to disk and tape with certain retention
policies are all part of this plan.
So what options are available in Oracle to protect the data against those
“oops” or “oh no” moments? Besides the backups, there are exports, a
recycle bin, and a way to flashback queries and even the database. We’ll

start with some of the commands for backing up the database, and then
progress through the other options.
Backup and Restore Commands
The basic commands for backing up and restoring Oracle databases should
look familiar to SQL Server DBAs. Let’s start with the SQL Server command
to back up a database:
backup database customer_db to
disk ='E:\mssql\bkups\customer_db_02022010.bak'
backup log customer_db to
disk='E:\mssql\bkups\customer_db_log_02022010.trn'
This will take care of the SQL Server database and log backups, and
write the backup file to disk.
In Oracle, you use a Recovery Manager (RMAN) command, like this:
RMAN> run {
allocate channel disk1 device type disk;
backup database plus archivelog;
}
This command will back up the database with the archive logs and write
the backup file to disk.
Chapter 6: Database Backup, Restore, and Recovery
129
Here is the SQL Server command to restore a database:
restore database customer_db from
disk ='E:\mssql\bkups\customer_db_02022010.bak'
The Oracle RMAN command is basically the same:
RMAN> run {
allocate channel disk1 device type disk;
restore database;
}
Both database platforms can perform “hot backups” while the database

is up and available, when it’s possible that changes are happening as the
backup is running. The transaction and archive logs keep these changes, so
these logs must be part of the backup set.
NOTE
RMAN puts the database (datafiles and
tablespaces) in backup mode when it runs the
backups. If you’re not using RMAN, you’ll need
to issue
ALTER DATABASE BEGIN BACKUP
before being able to do a hot backup of the
database.
Typically, 24/7 access to the database is required, so hot backups are
made. However, there might be opportunities to take a cold backup when
the downtime is available, such as before an upgrade or hardware move.
This will get a full backup, so the transaction and archive logs do not need
to be handled. In SQL Server, if the instance services are shut down for a
cold backup, the files can be copied over. The same is true for Oracle
databases. This script runs a cold backup:
RMAN> run {
shutdown immediate
startup mount
allocate channel disk1 device type disk;
backup database;
}
130
Oracle Database Administration for Microsoft SQL Server DBAs
Looking at the script, you may wonder why there is a startup. The
startup mount command will allow RMAN to read the control files to
know which datafiles need to be backed up. The database server is still not
available, so the files can be copied and backed up by RMAN in this “cold”

state.
Since the database is down for a cold backup, the datafiles can be
copied without using RMAN. Scripts can be written using operating system
commands to just copy the datafiles to another location, tape, or another
mount point while the database is down. A shell script or batch file can shut
down the database, and then cp/copy commands can be issued to copy the
datafiles, or a file system backup can be done. This type of cold backup
would not need the database in mount state, because it wouldn’t be using
the control file, as RMAN does.
As you can see from the examples, RMAN is a big part of the backup
and restore strategies for Oracle databases. RMAN can be used through the
command line as well as OEM. We’ve skipped over a few pieces in these
examples. As you’ll learn next, RMAN requires some configuration to be
able to run backups.
RMAN Configuration for Backups
RMAN is installed with the Oracle software and placed in the ORACLE_
HOME/bin/ directory. RMAN can use a catalog to track and manage the
backups, or it can use the control file of the database for this purpose.
A database must be available to be able to create the schema needed
for the RMAN catalog. One catalog can manage the backups of several
databases, but the catalog should be at the same database version as the
databases being backed up.
To configure RMAN, create a user to be catalog owner, and grant that
user a quota on the tablespace where the schema is going to live, as well as
the RECOVERY_CATALOG_OWNER role. Next, create the catalog using the
RMAN command line:
>rman
RMAN> connect target
connected to target database: DBDEV1 (DBID=280973718)
DBDEV1 will be the database that will have the catalog schema.

Chapter 6: Database Backup, Restore, and Recovery
131