fyi...here is some info on the DataTools SQL-BackTrack module
for Oracle which allows Oracle databases to be backed up
incrementally while online to an ADSM server. I previously
appended some info on the same function from DataTools for
backing up Sybase databases to ADSM....Greg Tevis
======================================================================
SQL-BackTrack for Oracle is currently available for
SunSparcs running SunOS 4.1.3 or Solaris 2.x, HP9000/8xx
running HP/UX 9.x or 10.x. The IBM RS6K/AIX version is
in beta test mode and will be released by November 1.
I've attached a few abstracts on the Oracle product:
1) data sheet
2) white paper discussing Oracle backup and
recovery
3) on-line demo instructions for SQL-BT Oracle
and Sybase
Please broadcast and if you have any questions, holler!
Cheers,
//Ron Aviles
DataTools, Inc. http://www.datatools.com
3343 Hillview Ave
Palo Alto, CA 94304
rja AT datatools DOT com
415.842.9141
SQL-BACKTRACK FOR ORACLE BACKUP AND RECOVERY
********************************************
SQL-BackTrack for Oracle is DataTools' powerful database-aware
backup and recovery tool. This integrated solution automates
most of your backup and recovery tasks, including any
combination of cold, offline or online backups, archive log
management, and regular exports.
Key features are:
* Complete suppport of Oracle version 7.0 and above
* Support for both physical and export backups
* Time-saving automation and media management features
* Fast parallel backup streams, and compression
* Automatic backup of new tablespaces and data files
* Full integration with popular file system backup solutions
* Fail-safe, dry-run data verification
* Easy-to-use, menu-driven interface
* Reliable encryption of valuable data
* Direct backup to tape
Platforms supported are:
* Sun SPARC running SunOS 4.1.3 or Solaris 2.3 and above
* HP/9000 Series 700 or 800 running HP/UX 9.0 and above
* IBM RS/6000 running AIX 3.2 and above
DataTools, Inc. develops products that provide database
administrators with mainframe-class database management tools
for client/server computing. For more information, post to
info AT datatools DOT com.
REDUCING RISKS TO CLIENT/SERVER DATA
DataTools, Inc. Whitepaper
Oracle Database Backup and Recovery
***********************************
The allure of client/server architecture is very strong for those who
want to downsize from a mainframe environment. It promises, among other
things, local ownership of local data and distributed processing.
Oracle, as the leading vendor of relational database management systems
(RDBMSs), is at the heart of this revolution, providing the backbone
for increasing numbers of production client/server applications running
key information systems around the world.
Unfortunately, the client/server model introduces complexities in data
administration and protection. Mission-critical data must be protected,
whether it is stored locally or centrally. Unlike the mainframe
environment with its centralized operations staff, sophisticated tools
and standardized procedures, client/server applications reside in an open,
often fluid, environment. The very aspects that make it so attractive
(heterogeneous environments,smaller IS staff, distributed computers) can
make administering and securing data a nightmare.
Even in a centralized IS environment, client/server databases typically
lack the sophisticated backup and recovery tools which were taken for
granted on the mainframe system. Existing backup and recovery procedures
for Oracle are complex to learn, deploy and maintain, leaving core
applications vulnerable to failures or long outages.
Wherever backups are inadequate or inconsistently performed, valuable data
is at risk. With the growing number of client/server applications maturing
and supporting vital corporate functions, ever-increasing amounts of critical
data are being put at risk.
This paper outlines the main problems with today's methods for Oracle
database backup and recovery, followed by a strategy for solving these
problems using SQL-BackTrack for Oracle from DataTools, Inc.
PROBLEMS WITH ORACLE BACKUP/RECOVERY TODAY
******************************************
Overview
Current backup and recovery methods for production Oracle databases not only
take up a great deal of time, they also demand a high level of expertise from
database administrators (DBAs).
To carry out successful backup and recovery using traditional methods, DBAs
first need a comprehensive understanding of the structure of the database and
the relationships between the files. They need to write, or have written,
reliable scripts for backing up all of the necessary database components.
They need to maintain these scripts consistently as database files are added
or changed.
Once the system is in place and running, DBAs need to perform and carefully
track database exports, which requires a good system for identifying and
locating the actual backup tapes and files. In practice, this tracking system
may be maintained by the DBA, the system administrator (SA), or some
combination of the two.
Database recovery relies even more heavily on the DBA not only correctly
retrieving the files but understanding the nature of the failure, identifying
the correct files to retrieve, and performing the appropriate actions to
recover the database. Again and again, the heavy reliance on the DBAs presence
and expertise leaves some institutions vulnerable to failure because they
cannot reach the right person, or because they are experiencing turnover in
the DBA group.
THE RISKS IN DETAIL
********************
The risks to data can be classified as five key areas in the development and
implementation of a backup/recovery strategy:
1. Establishing the backup procedure
2. Maintaining the backup procedure
3. Recovering data
4. Adjusting for growth
5. Cross-system interaction
Area 1: Establishing the backup procedure
The three mainstays of a comprehensive backup and recovery plan are:
* Physical backups (usually a combination of cold and hot backups)
* Reachieved redo log management
* Regular database exports
If one of these is missing, it may not be possible to recover from some
failures. The human component is of such importance here that obtaining the
services of a well-qualified DBA is often critical. However:
* As the range of Oracle applications continues to expand, good DBAs
are becoming harder to find.
* Organizations with experienced DBAs are always at risk of losing
them; turnover rates are high.
* Isolated departments in organizations that are beginning to hold
mission-critical data may not have the expertise locally to set up or
adhere to standard backup procedures. They may not even recognize that
they need to do this.
Area 2: Maintaining the backup procedure
Most Oracle DBAs have heard the story of the DBA who added a data file but
forgot to modify the backup script and found after a failure that there were no
backups. It may just be a DBA legend (no one has admitted it to us yet), but it
does highlight a basic flaw in the process; ongoing vigilance is required to
keep the backups up to date.
Also, it is often the case that the people who write the backup scripts are not
involved in the maintenance process; they may even work for a different company.
As one manager at a major financial institution told us, "We're okay as long as
those consultants who set it up are still around."
Setting up the backup procedure is often the task of the consultants or
developers who build the application and who move on to other projects,
departments, or companies when the project is complete. If the scripts
themselves are not easily maintainable, the DBA responsible for the database
may ultimately have to create a new backup procedure from scratch.
Area 3: Recovering data
Like the backup process, Oracle database recovery requires a detailed
understanding of the nature of the failure, exact information about what
data is required to be recovered, and a comprehensive understanding of the
Oracle database structure and recovery processes. The inevitability of
failure occurring at a supremely inconvenient time simply adds to the
pressure under which DBAs must work.
It is possible to have all the right pieces available for a recovery, and
still not put them together correctly for a consistent database recovery.
In some sites, a system administrator is responsible for writing to tape the
actual files that comprise the database, and for recovering them from tape.
In this case, the DBA cannot perform a recovery alone. It now depends not only
on the DBA's expertise and time, but also the system administrator's
experience in finding and recovering specific files. Inefficient communication
between the two will delay a complete recovery and may result in a key
application being unavailable for a prolonged period.
Area 4: Adjusting for growth
Even with a devoted and knowledgeable DBA, flawless scripts, fast tape drives,
and happy users, there is no assurance that a current backup system will
continue to work as the database grows. A backup system that's fine for a 2G
database may be unacceptable for a 20G database and impossible for 200G.
Many DBAs anticipate significant growth in both database size and usage
requirements for the applications they maintain; very few have determined how
they will work with those growth requirements. Most are optimistically
counting on the database vendors supplying something before the problem
becomes critical.
Area 5: Cross-system integration
Database vendors often provide no tools or guidance on backup and recovery
issues, and any administrative tools they will supply are for their own
databases. Sites with more than one vendor's database in-house must either
maintain separate, different procedures for each type of database, or look
for an integrated solution which uses common procedures for all
mission-critical databases.
Summary. The problems, therefore, are manifold. They occur with staffing,
with the supply of tools, and the complexities of creating an efficient backup
system and of recovering from a failure. The likelihood that databases will
continue to increase in size simply compounds the problems outlined above.
There is clearly a requirement for tools which are specifically designed to
manage large databases, though it is often beyond the scope of database
vendors to develop such software.
MAINFRAME-CLASS SOLUTIONS FOR CLIENT/SERVER PROBLEMS
****************************************************
DataTools, Inc. provides administrative tools for production client/server
databases. As a member of the Oracle Business Alliance Programme and the
Oracle Systems Management Tools Initiative (SMTI), DataTools works closely
with Oracle to support and maintain its products, and to ensure that those
products fit well into the overall Oracle portfolio of products. DataTools is
a specialist in the field, and as such can develop a more comprehensive and
sophisticated range of tools than those offered by database vendors like
Oracle.
DataTools' aim is to bring mainframe-class management software to
client/server databases; SQL-BackTrack for Oracle is one example of such
software.
When designing SQL-BackTrack for Oracle, DataTools engineers looked at the
complete scope of backup and recovery tasks that DBAs face in the Oracle
environment, including maintaining backup configurations and performing complex
recoveries. They studied not only the technical issues but also the human
issues: what do inexperienced DBAs find difficult; where do even experienced
DBAs make mistakes? The resulting product is one that not only has powerful
technical features (incremental backups, for example), but that also
significantly simplifies a DBAs tasks and by doing so helps ensure the safety
of vital data.
How does SQL-BackTrack deal with the four areas, described earlier, in which
problems occur?
Area 1: Automating the backup procedure
SQL-BackTrack for Oracle has a menu-driven interface (OBACKTRACK) that queries
the running database and tracks all its components in order to create a backup
profile for the database. This profile ensures that important data files are
never omitted from the backup process. OBACKTRACK's menu interface also guides
the DBA through backup and, more importantly, through recovery.
Archive log management is also a critical part of the backup process.
SQL-BackTrack's backup will write archive logs to tape and either rename or
delete them, according to the plan set up by the DBA. BackTrack also allows the
DBA to schedule automated exports to tape, controlling the trusted Oracle exp
facility through the SQL-BackTrack interface.
The backup profile contains all the information needed for unattended backups,
allowing complete automation of the backup process. The DBA can design the
backup
schedule (full or partial, cold, off-line or on-line) according to the system's
needs. BackTrack records each backup and its location on-line, thus eliminating
the need for the DBA or SA to trace the location of each backup manually.
SQL-BackTrack has further advantages. It offers ANSI labeled tape support, a
system for making each backup tape self-describing, thus reducing the chance of
mislabeling a tape. Data compression makes efficient use of tape storage, and
encryption protects particularly sensitive data from being reloaded by anyone
without the encryption key.
Area 2: Automating backup maintenance
When performing an on-line backup, SQL-BackTrack for Oracle checks for added
data
files or table spaces and automatically adds them to the backup profile. Backups
that fail can be automatically restarted, and there are no scripts to create or
maintain. With automatic maintenance of the backup profile, new data files are
no longer in danger of being omitted from backup scripts.
Area 3: Automating quick and appropriate recovery
People don't always think clearly in times of recovery crises, so SQL-BackTrack
offers a guided recovery mode. Its menu-driven interface allows a DBA to
identify
the type of failure and then constructs the appropriate backup procedure for
that
failure. It loads the necessary files, prompting for tapes when necessary, and
recovers the database. For DBAs who wish to retain complete control,
SQL-BackTrack
can also be used simply to locate and restore the physical files, or to
generate a
list of SQL commands to be used in recovery.
SQL-BackTrack reduces the DBA's dependence on a system administrator to restore
files by tracking the backup file location on-line. It prompts for the
appropriate
tapes, alleviating a point of weakness for larger systems and speeding the
overall
recovery process.
Area 4: Adapting for growth
SQL-BackTrack for Oracle has a number of features that address the needs of very
large databases, or databases with high availability requirements:
* Parallel backup and recovery streams provide fast performance for very
large databases.
* Incremental backups write only the data blocks rather than complete
files
that have changed since the last backup. This provides the security
of a
full backup without the disk space it requires.
* Data compression reduces most physical backups to 40% or less of their
uncompressed size, allowing larger databases to be written faster and
to fit on fewer tapes.
Area 5: Cross-system integration
Organizations that use both Sybase and Oracle databases can use SQL-BackTrack
to automate and manage backups for both kinds of servers. This provides
additional standardization and backup security at an enterprise level.
DBAs can also fit database backups into the enterprise-wide backup scheme,
leveraging an existing investment in backup hardware/software used for
network-based backups. SQL-BackTrack has optional modules for integration with
the following network-wide backup products:
* Legato NetWorker
* IBM ADSM
* EMC EpochBackup
* AT&T CommVault Backup
A number of other file system backup companies have developed or are
developing interfaces for SQL-BackTrack backups; these include Alexandria from
SpectraLogics and ARCserve from Cheyenne Software.
DataTools' SQL-BackTrack for Oracle is a powerful and versatile product that
gives DBAs the tools they need to protect mission-critical data stored in Oracle
databases. DBAs have the benefit of simplified administration and protection of
vital data; the organizations they support can have peace of mind that their
data, even if distributed on many different servers running different software,
is protected.
SQL-BackTrack is a trademark of DataTools, Inc. All other trade names referenced
are the property of the respective manufacturer.
|
