Download Enterprise eTIME Database Administrator`s Guide

Enterprise eTIME
Database Administrator’s Guide
®
An administrator’s guide to maintaining the Enterprise eTIME
Suite database for your Enterprise eTIME Suite time and
labor management applications.
Enterprise eTIME Suite Version 4
Document Part Number: 4702839-002
Document Revision: A
The information in this document is subject to change without notice and should not be construed as a commitment
by ADP, Inc. ADP is not responsible for any technical inaccuracies or typographical errors which may be contained
in this publication. Changes are periodically made to the information herein, and such changes will be incorporated
in new editions of this publication. ADP may make improvements and/or changes in the product and/or the programs
described in this publication at any time without notice.
This document or any part thereof may not be reproduced in any form without the written permission of Kronos
Incorporated. All rights reserved. © 2001—2003 Kronos Incorporated.
ADP provides this publication "as is" without warranty of any kind, either express or implied, including, but not limited
to, the implied warranties of merchantability or fitness for a particular purpose.
The ADP Logo is a registered trademark of ADP of North America, Inc. eTIME is a registered trademark of
Automatic Data Processing, Inc.
CardSaver, Datakeeper, Datakeeper Central, Gatekeeper, Gatekeeper Central, Imagekeeper, Jobkeeper,
Jobkeeper Central, Keep.Trac, Kronos, the Kronos logo, ShopTrac, ShopTrac Pro, the ShopTrac logo, Solution In A
Box, Start.Time, TeleTime, Timekeeper, Timekeeper Central, TimeMaker, and Visionware are registered trademarks
of Kronos Incorporated. CommLink, Comm.Mgr, DKC/Datalink, HyperFind, Improving the Performance of People
and Business, Kronos Connect, Kronos e-Central, Labor Plus, Prism, Smart Scheduler, Starter Series, Start.Labor,
Start.Quality, Start.WIP, Tempo, the Tempo logo, Timekeeper Decisions, Timekeeper Express, Timekeeper Web,
Workforce Activities, Workforce Accruals, Workforce Central, Workforce Central Suite logo, Workforce Decisions,
Workforce Express, Workforce Manager, Workforce Scheduler, Workforce Smart Scheduler, Workforce TeleTime,
Workforce Timekeeper, Workforce Genie, Workforce MobileTime, Workforce Professional Time, and Workforce Web
are trademarks of Kronos Incorporated.
All other trademarks or registered trademarks used herein are the property of their respective owners and are used
for identification purposes only.
When using and applying the information generated by ADP products, customers should ensure that they comply
with the applicable requirements of federal and state law, such as the Fair Labor Standards Act.
Published by ADP, Inc.
Automatic Data Processing, Inc.
ADP Time & Labor Management
5800 Windward Parkway
Alpharetta, GA 30005
(800)543-7994
For more information, see the following ADP, Inc. Web page:
http://www.adp.com
Document Revision History
Document Revision
Product Version
Release Date
A
Enterprise eTIME 4.3
February 2003
Contents
Contents
About This Guide
Organization of This Guide ........................................................................viii
Enterprise eTIME Documents ...................................................................... ix
Chapter 1: Introduction
About the Enterprise eTIME Database .......................................................1-2
DBA Goals in the Enterprise eTIME Environment ...................................1-4
Database Design ...................................................................................1-4
Installation and Configuration .............................................................1-4
Availability ..........................................................................................1-5
Performance Analysis ..........................................................................1-5
Maintenance .........................................................................................1-5
Disaster Recovery ................................................................................1-6
Building a Maintenance Schedule .....................................................1-10
Chapter 2: Managing Your Oracle Database
Introduction ................................................................................................2-2
For Additional Information ..................................................................2-3
Overview of Oracle Architecture ...............................................................2-4
Structure of the Database .....................................................................2-4
Structure of the Database Instance .......................................................2-6
Managing Components of an Oracle Database ........................................2-10
Special Recommendations .................................................................2-10
Managing Parameter Files .................................................................2-12
Managing Control Files .....................................................................2-13
Managing Databases and Instances ...................................................2-14
Managing Tablespaces and Datafiles .................................................2-22
Contents
Managing Redo Log Files ........................................................................ 2-28
Understanding How Online Redo Logs Work .................................. 2-28
Creating Online Redo Log Files and Log Groups ............................. 2-33
Viewing Information About Online Redo Log Files ......................... 2-34
Archived Redo Logs and ARCHIVELOGMODE ............................ 2-36
Backup Procedures ................................................................................... 2-40
Performing Physical Backups ............................................................ 2-40
Performing Logical Backups ............................................................. 2-43
Performing Partial Backups ............................................................... 2-47
If You Run Out of Redo Log Space .................................................. 2-47
If You Lose a Redo Log Group ......................................................... 2-47
If You Run Out of Archive Log Space .............................................. 2-48
Recovering and Restoring Damaged Databases ...................................... 2-50
Instance Recovery ............................................................................. 2-50
When Instance Recovery Is Not Enough ........................................... 2-51
Determining Which Recovery Strategy to Use ................................. 2-54
Improving Performance of Recovery ................................................ 2-59
Integrity Checking .................................................................................... 2-61
Enabling Redo Log Block Checking ................................................. 2-61
Updating ROWID Values .................................................................. 2-61
Verifying Access to Files .................................................................. 2-62
Performance and Tuning .......................................................................... 2-63
Checking the ALERT File ................................................................. 2-63
Correcting LGWR Delays ................................................................. 2-63
If Sessions Are Waiting for Other Sessions ...................................... 2-63
Using DBReport ................................................................................ 2-64
Rebuilding Indexes ............................................................................ 2-65
Rebuilding Tables .............................................................................. 2-67
Coalescing Free Extents .................................................................... 2-67
Updating Statistics ............................................................................. 2-68
Recompiling Stored Procedures ........................................................ 2-70
Hardware Solutions ........................................................................... 2-70
iv
ADP, Inc.
Contents
Chapter 3: Managing Your SQL Server 2000 Database
Introduction ................................................................................................3-2
Managing SQL Server 2000 .......................................................................3-3
Using SQL Server Enterprise Manager for Database Management ....3-3
Using SQL Statements for Database Management ..............................3-7
Managing Components of a SQL Server 2000 Database ...........................3-8
Managing Databases ............................................................................3-8
Managing Transaction Logs ..............................................................3-11
Managing Filegroups .........................................................................3-12
Managing Backups .............................................................................3-15
Performing Backups .................................................................................3-18
Performing Full Backups ...................................................................3-18
Performing Incremental Backups ......................................................3-20
What Happens During Backup ..........................................................3-22
Backing Up a Full Transaction Log ...................................................3-22
Hot and Warm Backups .....................................................................3-23
Restoring Damaged Databases .................................................................3-24
Before You Start ................................................................................3-24
Automatic Recovery ..........................................................................3-24
Restoring a Complete Database Backup ............................................3-25
Restoring When the Database Must Be Re-created ...........................3-27
Restoring a Corrupt Database ............................................................3-27
Recovering the Master Database .......................................................3-27
Integrity Checking with DBCC ................................................................3-29
Using Checkdb ...................................................................................3-29
Performance Analysis and Tuning ...........................................................3-30
Understanding the DBReport Utility .................................................3-30
Rebuilding Indexes ...................................................................................3-32
Overview ............................................................................................3-32
Dropping and Re-creating Indexes and Other Dependent Objects ....3-33
Performing Automatic Backups ...............................................................3-34
Scheduling Maintenance Through SQL Server
Enterprise Manager .................................................................3-34
Running Maintenance Utilities from DOS Batch Files .....................3-35
Enterprise eTIME Database Administrator’s Guide
v
Contents
Chapter 4: Installing and Configuring Automated SQL Server Database
Maintenance Utilities Scripts
About the Automated Database Maintenance Utilities .............................. 4-2
System Requirements ................................................................................. 4-3
Installation Checklists ................................................................................ 4-4
Enterprise eTIME Database Installation Tasks ................................... 4-4
Automated Database Maintenance Utilities Tasks .............................. 4-5
Performing Automated Database Maintenance Utilities Tasks ................. 4-6
Analyze Server Disk Space ................................................................. 4-6
Create Backup and Log Directories .................................................... 4-7
Create SQL Server Database Backup Devices .................................... 4-8
Install Maintenance Task Jobs ............................................................. 4-9
Activate the Jobs .................................................................................. 4-9
Test the Jobs ...................................................................................... 4-11
Job Details ......................................................................................... 4-12
Viewing Jobs ..................................................................................... 4-14
Chapter 5: Maintaining the SQL Server Database with Automated
Database Maintenance Utilities
Database Tasks ........................................................................................... 5-2
Review the Maintenance Log Files ............................................................ 5-3
Review the Maintenance Job Messages .............................................. 5-4
Back Up the Database Files ....................................................................... 5-8
Index
vi
ADP, Inc.
About This Guide
This guide explains the database administrator’s responsibilities and the tasks you
must perform to keep your Enterprise eTIME® database in good working order.
Tasks include:
w
Developing a backup and restore strategy
w
Managing the database’s physical components
w
Performing backups
w
Recovering from disasters
w
Analyzing performance and performing other day-to-day maintenance
This preface contains the following sections:
w
Organization of This Guide
w
Enterprise eTIME Documents
Note
This guide does not take the place of training in database administration.
ADP strongly recommends that each person responsible for installing, upgrading,
or maintaining databases at your company take a course in database
administration and consult other reference materials before attempting to perform
the operations described in this book.
ADP also strongly recommends that you set up a test system where you can
practice database management techniques in a nonproduction environment before
you attempt to install or maintain a production Enterprise eTIME database.
About This Guide
Organization of This Guide
Chapters in this guide provide the following information:
w
Chapter 1, “Introduction,” describes the basic tasks a database administrator
must perform to properly maintain and tune the Enterprise eTIME database.
These tasks include:
–
Planning steps
–
Planning a recovery strategy
–
Backing up and maintaining the database
w
Chapter 2, “Managing Your Oracle Database,” includes instructions for
performing basic backup and maintenance operations on Enterprise eTIME
databases that use Oracle 8 or 8i.
w
Chapter 3, “Managing Your SQL Server 2000 Database,” includes
instructions for performing basic backup and maintenance operations on
Enterprise eTIME databases that use Microsoft SQL Server 2000.
w
Chapter 4, “Maintaining Your DB2 Database,” describes how to run the
database provided by ADP to obtain performance statistics and maintain your
DB2 database.
w
Chapter 4, “Installing and Configuring Automated SQL Server Database
Maintenance Utilities Scripts,” describes how to install and configure the
automated database that help you administer your SQL Server database.
w
Chapter 5, “Maintaining the SQL Server Database with Automated Database
Maintenance Utilities,” describes how to use the automated database utilities
with your SQL Server database.
w
The Appendix, “Database Configuration Settings,” contains information for
sites that use languages other than English in their database. It includes details
on character sets, code pages and language as well as asummary information
about configuration issues.
Each chapter includes lists of additional resources for readers who need more
training in a particular area.
viii
ADP, Inc.
Enterprise eTIME Documents
Enterprise eTIME Documents
The following documentation is available to help you install, maintain, and use
the Enterprise eTIME database and software:
w
Enterprise eTIME Installation Guide for Windows provides an overview of
the Enterprise eTIME architecture, outlines the system requirements, explains
how to install the product’s server and client components, and includes
licensing and upgrade requirements.
w
Enterprise eTIME Installation Guide for UNIX describes how to install the
Enterprise eTIME server on UNIX platforms. It provides an overview of the
Enterprise eTIME architecture, outlines the system requirements, and
explains how to install the Application Server and Background Processor on
UNIX platforms.
w
Workforce Timekeeper Installation and Reference Guide for DB2 on OS/390
is a reference for customers and Kronos personnel who install and use a
Workforce Timekeeper DB2 database on an OS/390 mainframe computer.
The manual explains hardware requirements, installation on the OS/390,
ZPARM and other system settings, and installation of the DB2 client
software.
w
Enterprise eTIME Kdemo Reference Guide explains how to install and use the
Kdemo software components for demonstration, training, and testing
purposes; and describes how to manage the Kdemo database and other
databases used with Kdemo. This guide also includes the Kdemo reference
tables and a sample Kdemo dataset.
w
Getting Started with Enterprise eTIME—A Guide for Managers explains
some of the most common tasks that managers are likely to perform. It
summarizes key product features for people who access employee time and
attendance information. The book also explains the various Enterprise eTIME
components and the most common tasks that managers are likely to perform
with each component.
w
Getting Started with Enterprise eTIME—A Guide for Employees (Java
version) explains some of the most common employee tasks, which include
using the Timecard and Time Stamp components, as well as viewing personal
schedules and reports.
Enterprise eTIME Database Administrator’s Guide
ix
About This Guide
x
w
Getting Started with Enterprise eTIME—A Guide for Employees (HTML
version) explains some of the most common employee tasks in Enterprise
eTIME Professional - HTML Client, which include using the Timecard, Time
Stamp, and Quick Time Stamp components, as well as viewing personal
reports.
w
Enterprise eTIME System Administrator’s Guide describes the administrator’s
activities, such as System Configuration and Setup. Activities that use the
System Configuration component are described in detail.
w
Enterprise eTIME Database Tables Reference Guide contains details about
the Enterprise eTIME database tables. This document is available in PDF
format only on the Enterprise eTIME CD-ROM.
w
Enterprise eTIME Database Installation Guide instructs customers and
service personnel who install or upgrade Enterprise eTIME databases.
Instructions include installing and setting up the Relational Database
Management System (RDBMS) and ADP application database components,
and upgrading your database components for compatibility with new versions
of Enterprise eTIME products.
w
Enterprise eTIME Database Administrator’s Guide explains how to maintain
the Oracle and SQL Server 2000 databases for Enterprise eTIME. This guide
includes procedures for backing up databases, restoring and recovering
databases, adjusting performance, and using maintenance utilities.
w
Enterprise eTIME Import Guide: Table Format provides instructions and
table data for Enterprise eTIME Import tables. It also contains a brief user
guide for the Import workspace.
w
Enterprise eTIME Database Views Reference Guide provides information and
details about Views and how they are used as virtual tables in Enterprise
eTIME.
w
Guide to Translating and Customizing the Workforce Timekeeper User
Interface and Online Help provides instructions for editing the browser-based
graphical user interface and the associated browser-based Help files. This
guide is available in PDF format only on the Translation and Customization
Toolkit CD (ordered separately).
ADP, Inc.
Enterprise eTIME Documents
w
Developer’s Toolkit documentation: Enterprise eTIME includes an
Application Program Interface (API) that you can use to access certain
Enterprise eTIME features from application programs. The Enterprise eTIME
Developer’s Toolkit Programmer’s Guide includes annotated sample
programs that show how to use the API, and the Enterprise eTIME
Developer’s Toolkit Reference Guide provides detailed information about each
element of the API.
w
Online Help for the Enterprise eTIME system is installed automatically with
the product. To access online Help: click the Help link at the bottom of the
navigation bar; click the Help icon in the component; or click the Help button
in a dialog box.
w
Release notes provide additional information about Enterprise eTIME,
including a list of new features, resolved issues, and late-breaking changes.
Enterprise eTIME Database Administrator’s Guide
xi
About This Guide
xii
ADP, Inc.
Chapter 1
Introduction
The Enterprise eTIME database needs periodic maintenance and tuning. Without
such maintenance, database operations can become considerably slower over
time.
Note
This guide does not take the place of training in database administration.
ADP strongly recommends that each person responsible for installing, upgrading,
or maintaining databases at your company take a course in database
administration and consult other reference materials before attempting to perform
the operations described in this guide.
ADP also strongly recommends that you set up a test system where you can
practice database management techniques in a nonproduction environment before
you attempt to install or maintain a production Enterprise eTIME database.
This chapter contains the following sections:
w
About the Enterprise eTIME Database
w
DBA Goals in the Enterprise eTIME Environment
Chapter 1
Introduction
About the Enterprise eTIME Database
The Enterprise eTIME system uses a three-tier application structure to deliver
functionality to the desktop.
w
The client uses a Web browser to access the applications. Application
functions are presented as HTML pages or as Java applets.
w
The application server tier consists of one or more application servers.
w
The third tier is the database server, containing all of the Enterprise eTIME
data.
The following figure shows this structure:
The database server holds the relational database used by all your Enterprise
eTIME applications. You can use an Oracle or SQL Server on any of several
different operating systems and platforms. All relational database systems provide
similar functions, but the terminology differs. Oracle, for instance, refers to
“backup” and “online redo logs,” while SQL Server uses the terms “dump” and
“transaction logs.”
1-2
ADP, Inc.
About the Enterprise eTIME Database
This guide describes only tasks and procedures that you perform on the database
server. It does not give instructions about how to configure the network or
perform system administration tasks specific to any of the Enterprise eTIME
applications.
Enterprise eTIME Database Administrator’s Guide
1-3
Chapter 1
Introduction
DBA Goals in the Enterprise eTIME Environment
The database administrator’s (DBA) job is to make sure the database is up and
running whenever it is needed. This means that the database must be:
w
Properly designed, so that its indexes reference frequently used fields, its
segmentation and partitions work efficiently, and so forth (design)
w
Set up and made accessible over the network (installation and configuration)
w
Available when users need it (availability)
w
Timely, allowing users to receive the data they request in a reasonable period
of time (performance analysis and training)
w
Accurate, with no database corruption or system errors (maintenance)
w
Returned to normal as quickly as possible after failure (disaster recovery)
The following sections describe the tasks you must perform to meet these goals.
Database Design
Database design is usually part of the database administrator’s job, but the
Enterprise eTIME database itself addresses those design issues. It defines the
segmentation, indexing, and stored procedures it needs. Its tables have already
been analyzed for performance.
Installation and Configuration
The Enterprise eTIME system requires you to install your database management
software, create a new database, and configure it appropriately before you install
the Enterprise eTIME system. Follow the installation instructions for your
database management software to install it on your system. The Enterprise eTIME
Database Installation Guide describes how to build the database for the
Enterprise eTIME applications to use. If there are additional requirements, you
will find them in the installation guide for your particular Enterprise eTIME
application.
1-4
ADP, Inc.
DBA Goals in the Enterprise eTIME Environment
Availability
Different applications have different availability requirements. The central
database for a corporation with offices worldwide will have to be available 24
hours a day, seven days a week. A small company with a single location might
shut down the database overnight. Other applications can be shut down
periodically for maintenance. Your application’s availability requirements will
influence how you perform many maintenance and disaster recovery tasks.
Performance Analysis
Performance analysis includes tasks such as making sure the database has
adequate memory and disk resources, adjusting the size of in-memory structures
for efficient operation, and monitoring usage patterns.
Maintenance
Maintenance includes ongoing tasks such as updating database statistics,
recompiling stored procedures, and rebuilding and reclustering tables and indexes.
Without such maintenance, database operations can become considerably slower
over time, so maintenance is closely related to performance. Your maintenance
and strategy will vary depending on your company’s business needs, as well as on
the hardware and software resources available to you.
Caution
ADP strongly recommends that you back up your database before performing any
maintenance.
Enterprise eTIME Database Administrator’s Guide
1-5
Chapter 1
Introduction
The Enterprise eTIME database provides a number of scripts to make
maintenance easier:
w
DBReport displays current information about the tables and indexes in the
database. The information that is included in the report varies depending on
which database you are using.
w
The DDL scripts generate SQL statements that allow you to drop database
objects so you can:
–
Avoid referential integrity errors while rebuilding or reclustering indexes
–
Improve performance of large operations
After the operation finishes, run the re-create script to return the dropped
objects to their former state.
w
The Stats utility runs your database’s command to update the statistical
information. The optimizer uses this data to determine the best access path for
data operations.
w
The Recomp utility lets you recompile all of the Enterprise eTIME stored
procedures to take advantage of the updated database statistics.
For details about how to use these utilities, see the appropriate section of the
chapter that describes your database system.
Disaster Recovery
Disaster recovery procedures include two phases:
w
Regularly backing up the database so you have the information necessary to
rebuild the database after a disaster.
Backup is the process of making a copy of your database and its data so that
they can be reconstructed from scratch without reference to the original copy.
w
Re-creating the database if a disaster actually occurs.
This reconstruction is called “restoring” or “recovering” the database. Most
database systems also support several forms of partial backup and restore.
“Backup” includes the idea of “restore.” You cannot restore your database to
its original condition if you did not back it up first.
1-6
ADP, Inc.
DBA Goals in the Enterprise eTIME Environment
Reasons to Perform Backups
You back up your databases because many events can damage a production
database:
w
Disk drives and other system components can fail and need to be replaced.
w
The entire system, including the disk drives, can be stolen.
w
Viruses can damage the database, disk, or system.
w
Physical disasters, such as an earthquake, burst pipes, or air conditioning
failure during a heat wave, can damage your facility and equipment.
w
The database can sustain accidental or malicious damage, such as when an
authorized user inadvertently deletes the PAYROLL table or a disgruntled
employee deliberately does the same thing.
w
Bugs in the system, disk, database, or application software can corrupt the
data or database structure.
w
A software, hardware, or network upgrade can fail, requiring you to restore
the old system to its original condition.
w
You might need to move the database to a new system, or move the entire
computer system to a new location.
Some of these events, such as virus damage and accidental deletions, might not be
detected immediately, requiring you to go through several backups to find a clean
copy of the database.
Enterprise eTIME Database Administrator’s Guide
1-7
Chapter 1
Introduction
Reasons to Back Up Your Database Separately
Unless you can shut down your database completely and ensure that all database
files are backed up together, you will need to back up your database separately
from other files on your network, using software tools especially designed for the
purpose.
Nightly disk backups are not generally adequate for backing up relational
database files for several reasons:
w
Most backup programs skip open files.
If the database is being used, it will not be backed up.
w
Database files can contain internal pointers and links to other files.
Disk backup programs do not recognize these pointers. For example, if parts
of the database are stored on different physical devices, and the physical
devices are backed up at different times, the parts might not be synchronized
after restoring from a disk backup.
w
If linked files are backed up at different times while operations are in
progress, the links can be out of sync.
Types of Backup
Databases provide two main types of backup:
w
Full backup copies everything in the database, including all database objects,
all data, and all other related files. Full backups can be physical copies of the
files or logical copies that include the instructions to reconstruct the database.
w
Incremental backup copies the portion of the database that has changed
since the last backup.
Note
Different database systems use different terminology to describe backups. In SQL
Server, for example, backups are commonly called “dumps” because the TransactSQL command to perform the backup is DUMP. This guide uses “backup”
throughout.
1-8
ADP, Inc.
DBA Goals in the Enterprise eTIME Environment
Backup and Recovery Strategy
You back up your database so that you can restore it to its original condition. It
does not matter how efficiently you perform backups if the backups are not
available when you need them or do not work when you try to use them.
Your backup strategy should consider issues such as these:
w
The frequency with which you need to do backups. Consider factors such as:
–
The amount of data you can afford to lose.
–
The level of activity of your database.
–
The amount of information that has to be backed up.
For example, small test or development databases might not need data
backup; instead, you can opt to rebuild and repopulate them. In that case,
you only back up the system files or scripts you need to re-create the
database.
w
The length of time it takes to perform a full backup of your database.
w
How long it takes to completely restore the database, whether that length of
time is acceptable, and, if not, how you can shorten the restoration time.
w
Whether you can shut down the database completely for backups (a cold
backup), or have to keep the database available (hot or warm backup).
w
Whether you can take advantage of times of low database use. Some
examples of low use times are the last week of the year, holiday weekends, or,
in academic environments, the database might be lightly used through the
summer. Most databases and operating systems provide performance
monitoring tools that help you analyze system usage and database demand to
locate low-use times.
w
The medium you use for your backups, and, if you back up to disk, how you
will back up the backups.
w
Whether you need new hardware, more air conditioning, or more power
outlets.
w
How you will test whether the backups can be recovered.
w
How you will verify that the data you are backing up is good.
Enterprise eTIME Database Administrator’s Guide
1-9
Chapter 1
Introduction
w
The number of incremental backups you want to accumulate before the next
full backup, and whether you want transaction logs at all. If your database is
small, it can be more efficient to back it up completely each time. High
availability systems that cannot afford any data loss can perform an
incremental backup every few minutes.
w
The number of backups you want to keep in your archive. You also need to
determine how you will manage the various backup files, and how you will
ensure you have the backup you need.
w
Where you will store the backups and for how long. You also need to
determine which personnel will be allowed to retrieve backups, how they will
retrieve them, and how long it will take to retrieve them (for example,
receiving permission or authorization to retrieve a backup).
In production environments where no data loss is acceptable, no cold backup is
possible, and no down time is allowable, you may want to investigate “hot”
strategies such as hardware mirroring, Redundant Array of Independent Disks
(RAID), or third-party backup systems, or “warm” strategies that allow a standby
system to go online quickly.
Building a Maintenance Schedule
Building one or more maintenance schedules will help to keep your Enterprise
eTIME database running at peak performance. Building a schedule is an iterative
process. You add something, test it, then add something more. It can take several
weeks before a full maintenance schedule is working successfully.
To create a maintenance schedule:
1. Determine available time, as discussed in “Backup and Recovery Strategy.”
2. Add backups.
Start the schedule with a full database backup, then add incremental backups.
3. Always make sure the backup is valid before you send it to storage. This is
especially important for tape backups, because head alignment and other
hardware errors can make a backup unusable.
1-10
ADP, Inc.
DBA Goals in the Enterprise eTIME Environment
4. Make sure the backup files are backed up as well. You can back up:
w
Directly to a tape
w
To a disk backup device, then copy the backup file to tape
w
To a disk backup device, then copy to a disk storage area
5. Test your recovery plan. If possible, simulate a disaster such as air
conditioning failure during a heat wave to make sure your emergency
procedures function as planned. At the very least, rebuild the database from
scratch using your backups and make sure your Enterprise eTIME system can
access the restored database.
After you establish a schedule of regular backups and verify that the backups
allow you to restore the database, you begin to add extra tasks:
1. Recalculate database statistics and recompile stored procedures.
Database statistics give the database the information it needs to efficiently
access data. If you regularly update those statistics and then recompile the
stored procedures to use the new statistics, your database will perform better.
These operations can be performed while the database is running.
2. Add index maintenance.
Using output from DBReport, identify the tables that need index maintenance.
Oracle databases can require defragmenting (see “Rebuilding Indexes” in
Chapter 2) while SQL Server databases might need reclustering (see
“Rebuilding Indexes” in Chapter 3).
Most index operations lock the target table or create an in-memory copy of it
to keep the database consistent while processing user requests. Maintaining
large or heavily used tables can drastically slow your system. To reduce the
impact, consider these options:
w
Schedule index maintenance for periods of reduced load.
w
Perform index maintenance as part of a scheduled shutdown.
3. Add integrity checking.
As necessary, run the integrity checking commands recommended for your
database. See Chapter 2 for Oracle databases, or Chapter 3 for SQL Server
databases. If you do not have enough time to run these commands during
routine maintenance, schedule them during slack periods or shutdowns.
Enterprise eTIME Database Administrator’s Guide
1-11
Chapter 1
1-12
Introduction
ADP, Inc.
Chapter 2
Managing Your Oracle Database
This chapter describes how to maintain, back up, and restore your Enterprise
eTIME databases on an Oracle8 or Oracle8i Relational Database Management
System (RDBMS).
This chapter contains the following sections:
w
Introduction
w
Overview of Oracle Architecture
w
Managing Components of an Oracle Database
w
Managing Redo Log Files
w
Backup Procedures
w
Recovering and Restoring Damaged Databases
w
Integrity Checking
w
Performance and Tuning
Chapter 2
Managing Your Oracle Database
Introduction
This chapter explains basic techniques for creating, maintaining, and backing up
Enterprise eTIME databases that use Oracle as their database management
system.
Oracle runs on a wide variety of operating systems and hardware platforms. At the
database management level, differences in the operating system affect the way
you perform many tasks:
w
Operating system commands are different.
w
File specifications and default locations can change.
w
The names of Oracle utilities can differ.
w
Methods of creating and invoking utilities and command files differ.
This chapter does not attempt to describe the differences. It does not explain all
possible ways to do a task, present complete SQL statement syntax, cover all
options, or describe every task that you might need to perform. You should rely on
your operating system documentation, Oracle operating system documentation, or
third-party references.
You have different tools available depending on which Oracle and operating
system version you are using and which Oracle options are installed. This chapter
uses SQL statements or the Server Manager (which is available with all Oracle
versions) to illustrate common maintenance operations. Other utilities, such as the
Windows NT Instance Manager, are explained as appropriate. If you want to use
the Oracle Enterprise Manager or other utilities, see the Oracle online
documentation for instructions and explanations.
To perform the operations described in this chapter, you should log on to the
Oracle instance as SYS, SYSTEM, or another user who has been assigned the
DBA role.
2-2
ADP, Inc.
Introduction
For Additional Information
If you need more detail about procedures, syntax, command options, or other
information not discussed in this chapter, refer to the following sources of
additional information.
Many good courses and books exist. This list does not include them all.
w
Oracle online manuals: Concepts, Administrator’s Guide, Backup &
Recovery, Tuning
References to Oracle online documentation refer to the Oracle8
documentation set.
w
Oracle Certified Professional Program:
http://www.oracle.com/education/certification
w
ORACLE8 DBA Handbook, by Kevin Loney, Oracle Press (Osborne/
McGraw-Hill)
This is a good book to start with if you have some background in
programming or databases but are not familiar with the DBA’s job.
w
Oracle8 Backup & Recovery Handbook, by Rama Velpuri, Anand Adkoli,
Oracle Press
w
Oracle 8i: The Complete Reference, by Kevin Loney and George Koch,
Oracle Press/McGraw Hill
Enterprise eTIME Database Administrator’s Guide
2-3
Chapter 2
Managing Your Oracle Database
Overview of Oracle Architecture
Unlike SQL Server, which uses a single central service to monitor and control all
databases on the system, Oracle treats each database and its associated resources
as separate from other Oracle databases on the same system. Individual databases
can be closed and inaccessible to users while other databases on the same system
are open and in use.
Unlike Microsoft SQL Server, Oracle does not use a central monitor or service to
manage every database on the system. Oracle distinguishes between the physical
files that hold the data, and the server processes and resources required to access
and manage the data:
w
The database is the data and the information about the data, stored as
physical files on the disk.
w
The database instance includes a memory area shared by all users who
access that database. and a set of background processes that perform services
on behalf of the users.
The distinction is important because the instance and the database are created and
managed separately. The following sections explain each aspect in more detail.
Structure of the Database
An Oracle database includes both a physical storage structure and a logical
storage structure:
w
2-4
The physical storage structure is made up of the actual files in which the
database is stored. This structure depends on the operating system on which
Oracle is running, but always includes these kinds of files:
–
A parameter file that specifies the characteristics of the database and the
database instance.
–
One or more control files, which specify information about the database
itself, including the physical location and characteristics of the other files.
When the database is started, Oracle reads the control file to identify the
files that must be opened and memory structures that must be allocated.
ADP, Inc.
Overview of Oracle Architecture
–
One or more datafiles, which store the logical objects. The datafile
created when the database is created is associated with the SYSTEM
tablespace and includes the system rollback segment.
–
Two or more online redo log files, which record every change made to
the database so changes can be recovered if the database or instance fails.
Two files are used so that one can be archived while the other is being
written. The archived files are called the archived redo log (sometimes
referred to as the offline redo log), and the log files collectively are called
the redo log.
Information in the redo log entries can be used to reconstruct all changes
made to the database, including the rollback segments.
w
The logical storage structure interprets the physical structure. All Oracle
databases have the same logical structure, no matter what the underlying
operating system is:
–
At the highest level, standard relational database schema objects such as
tables and indexes represent the data.
–
One or more tablespaces organize schema objects into logical groupings.
A tablespace is defined by one or more datafiles, into which it stores the
schema objects. A datafile is a physical file on the disk. You identify it by
its operating system name.
A datafile can belong to only one tablespace, and cannot be moved from
one tablespace or database to another. A tablespace, however, can include
more than one datafile, and you can add new datafiles at any time, up to a
maximum specified when the database is created.
–
A segment is a unit allocated within the tablespace. Each segment holds a
single kind of object. For instance, an index segment holds an index for a
table.
w
Each segment allocates extents as needed to store the segment’s data. This
allows the database to grow in a controlled fashion. Extents might or might
not be contiguous on the disk.
w
The smallest unit of logical storage is the data block. Data blocks hold the
actual rows of the table. The data block’s size is established when the database
is created and cannot be modified later.
Enterprise eTIME Database Administrator’s Guide
2-5
Chapter 2
Managing Your Oracle Database
Structure of the Database Instance
A database instance consists of a shared memory area and a set of processes that
perform database actions on behalf of user processes. The following sections
explain these components in more detail.
Processes
Oracle processes access the database on behalf of user processes. A process is an
operating system mechanism that can execute a series of steps; on some operating
systems it is called a job or a task. The structure of a process varies according to
the operating system’s features and the Oracle options being used. Oracle uses
three kinds of processes: user, server, and background.
User Processes
A user process supports a user session by executing the application or tool code.
For instance, when a user logs in to SQL*Plus, Oracle creates a user process to
run the application.
The user process communicates with the Oracle instance through a connection.
Most often the connection is a network link, but if the user process and Oracle
instance are on the same machine, interprocess communication mechanisms can
be used. A process normally uses its own private memory area, called the Program
Global Area (PGA). This memory is not shareable.
Server Processes
Server processes coordinate communication between the database instance and
the user process. Server processes perform tasks such as parsing and executing the
SQL statements for user processes, requesting services from background
processes, and returning data to user processes.
On some operating systems and Oracle configurations, the user process can be
combined with a server process. In other cases, many user processes connect to
the same server process.
2-6
ADP, Inc.
Overview of Oracle Architecture
Background Processes
Oracle divides its processing among a set of specialized background processes,
each of which performs one specific task. The number and kind of processes in a
particular database instance vary according to the operating system’s features and
the installed Oracle options.
w
The Database Writer process (DBWR) reads data from the database and
writes changed or inserted data to the database.
w
The Log Writer process (LGWR) copies redo log entries from the redo log
buffer in the System Global Area (see “System Global Area”) to the online
redo log file.
w
The System Monitor (SMON) performs several functions:
–
Performs instance recovery when the database starts up
–
Cleans up the database, eliminating transactional objects that are no
longer needed
–
Coalesces contiguous free extents into larger free extents
w
The Process Monitor (PMON) cleans up failed user processes by freeing the
resources, such as locks and memory, that the process was using. Like
SMON, it hibernates when not in use, waking up periodically to check to see
if there is work for it to do.
w
The Checkpoint process (CKPT) initiates database checkpoints. See
“Checkpoints.”
w
If your database runs with ARCHIVELOGMODE enabled, you should use an
Archiver process (ARCH) automatically to copy filled online redo log files to
the archive area for permanent storage and then make the redo log available to
LGWR for reuse. See “Archived Redo Logs and ARCHIVELOGMODE.”
Enterprise eTIME Database Administrator’s Guide
2-7
Chapter 2
Managing Your Oracle Database
Additional processes can be created for features such as Oracle Parallel Server,
distributed databases, Advanced Queuing, or multithreading. Enterprise eTIME
does not use any of these features.
Background processes are implemented differently on different operating
systems. Sometimes they are started as part of instance startup and sometimes
they are created by the Oracle installation. See your Oracle operating system
documentation if you need more information.
System Global Area
The System Global Area (SGA) is a shared memory area that contains the data
and control information for one Oracle instance. Users connected to the same
database share the same SGA. Oracle allocates the SGA when the instance starts
and deallocates it when the instance shuts down.
System Global Area
Database Buffer
Cache
Library
Cache
Data
Dictionary
Cache
Redo Log Buffer
Shared SQL Pool
2-8
ADP, Inc.
Overview of Oracle Architecture
The preceding figure illustrates the major sections of the system global area.
These sections include:
w
The database buffer cache holds a copy of data blocks recently read from
disk as a result of user SQL statements. When Oracle reads data from the disk
in response to a user’s request, it saves that data in a database buffer so that if
another user requests the same data, the data can be returned without another
disk I/O. When all database buffers are full, the most recently used data is
retained in memory and the oldest data is discarded to make room for new
information.
w
The redo log buffer contains information about changes made to the
database:
w
–
When Oracle commits a transaction, LGWR writes all log entries for that
transaction to the log files, adding a System Change Number (SCN) to
identify the transaction. The SCN is important for recovery.
–
When the redo log buffer is full, or another transaction commits, LGWR
writes all the entries to the log file, even though some of the entries can
belong to transactions that are still in progress.
The shared pool stores information that all user and background processes
need to access frequently. It is divided between two caches: the library cache
and the dictionary cache.
–
The library cache holds items such as SQL parse trees and execution
plans, code for stored procedures, and so on.
–
The data dictionary cache holds an in-memory copy of the contents of the
database’s data dictionary. Because Oracle must repeatedly consult the
information in the data dictionary to determine everything from index
structures to a user’s access rights, keeping the data dictionary in memory
greatly speeds performance.
Enterprise eTIME Database Administrator’s Guide
2-9
Chapter 2
Managing Your Oracle Database
Managing Components of an Oracle Database
The installation guide describes how to build the Enterprise eTIME database. The
following sections include background information to help you follow the
installation instructions. The following figure shows the recommended
configuration of an Enterprise eTIME database on Oracle:
Special Recommendations
ADP recommends that you perform the following tasks after installing the
database:
2-10
w
Run the Database Administrator (DBA) utilities
w
Review table storage
w
Change the initialization parameter setting
ADP, Inc.
Managing Components of an Oracle Database
Run the Database Administrator (DBA) Utilities
After installation of a new Enterprise eTIME database, the statistics reflect that all
tables are empty. Run the Stats and Recomp utilities frequently during ramp-up,
because even a small number of rows added to a table can impact the database
optimizer and the system’s performance.
For instructions about running these utilities for your DBMS, see the sections
“Updating Statistics” and “Recompiling Stored Procedures” later in this chapter.
Review Table Storage
Several tables in Enterprise eTIME can expand significantly, depending on the
number of people who are maintained in the system and the overall configuration
of rules in the system. You should closely monitor all tables in the database and
modify the storage parameters as necessary.
The parameters you monitor should include:
w
INITIAL
w
NEXT
w
MAXEXTENTS
The tables you monitor should include:
ACCRUALEDIT
ACCRUALTRAN
CARRYFORWARD
HOMEACCTHIST
PUNCHEVENT
SHFASGNWSHFMM
SHIFT
SHIFTAPPLYDATE
SHIFTASSIGNMNT
TIMESHEETITEM
WFCAUDIT
WFCEXCEPTION
WFCTOTAL
WORKEDSHIFT
Initialization Parameter Setting
ADP recommends setting the value of the shared_pool_size parameter to at least
300 MB. Because this value is quoted in bytes, the actual value should be no less
than 314572800.
Enterprise eTIME Database Administrator’s Guide
2-11
Chapter 2
Managing Your Oracle Database
Managing Parameter Files
The parameter file specifies the characteristics of the database: everything from
the database name to the size of the system global area. These values are referred
to as configuration parameters or database initialization parameters. Each
database has its own parameter file.
The convention for naming Oracle parameter files is:
w
$ORACLE_HOME\DATABASE\initSID.ora for Oracle on Windows NT
w
$ORACLE_HOME/dbs/initSID.ora for Oracle on UNIX
ORACLE_HOME is a logical name that identifies the Oracle installation
directory. The SID is a character string (one to four characters on Windows NT;
one to eight characters on UNIX) that identifies the Oracle instance that the
parameter file defines. For the Enterprise eTIME database, you might select
TKCS or KRON as the SID, making the parameter file name initTKCS.ora or
initKRON.ora. The parameter file is often referred to as the init.ora file or the
init*.ora file.
If your database was originally created on an earlier version of Oracle, you can
also have configuration parameters in files named config.ora or ora*.cfg; these
files are listed in the main initSID.ora file.
Creating a New Parameter File
To create the parameter file for a new database, start with the Oracle template file.
This is generally initORCL.ora for Windows NT if the Oracle installation created
a sample database file, and init.ora elsewhere.
For Oracle NT, the files are located in $ORACLE_HOME\DATABASE\
For Oracle on UNIX, the files are located in $ORACLE_HOME/dbs/
Edit the template file with any text editor. You must enter two parameters: the
database name and the control file location. In addition, the Enterprise eTIME
database requires setting several initialization parameters.
2-12
ADP, Inc.
Managing Components of an Oracle Database
The following example shows a portion of the initORCL.ora file that describes the
sample database:
db_name = oracle
db_files = 20
control_files = (C:\ORANT\DATABASE\ctl1orcl.ora,
C:\ORANT\DATABASE\ctl2orcl.ora)
compatible = 7.3.0.0.0
db_file_multiblock_read_count = 8 # INITIAL
You should also use DB_BLOCK_SIZE to specify a larger size value for the
database block. You cannot change the block size after you create the database
without rebuilding the database. The value you select for the Enterprise eTIME
database should be a multiple of the operating system block size.
If a database record is too long to fit in the free space of any database block, it is
chained across blocks—part of the record is located in one block and the rest of
the record in another block. Chaining slows performance because Oracle might
have to perform two I/Os to retrieve the entire record.
The Oracle default data block size is only 2K; records easily can be longer than
2K if they include several long text fields or if you use data types such as LONG.
You specify its size with the parameter when you create the database. You cannot
change the size of the database blocks after the database is created, so make sure
you select a large enough block now.
Managing Control Files
The control file is a small binary file that Oracle uses to start and operate the
database. Oracle creates one or more control files when it creates the instance. The
control files are associated with only one database and cannot be edited or
modified except by Oracle. Information in the control files includes:
w
The database name and timestamp of its creation
w
The names and locations of datafiles, online redo log files, and archive areas
w
The current log sequence number
w
Checkpoint information
Enterprise eTIME Database Administrator’s Guide
2-13
Chapter 2
Managing Your Oracle Database
Because Oracle constantly updates the control file, the file must be available for
writing whenever the database is mounted. If the control file becomes unavailable,
the instance crashes. For this reason, you should keep multiple copies of the
control file, preferably on separate disks. This is called multiplexing or
mirroring the control file. Whenever Oracle updates the control file, it updates all
copies at the same time. Oracle recommends that you keep a copy of the control
file on every disk where you keep any member of an online redo log group.
Be sure to back up the control file whenever you back up the rest of the database,
and after you make any changes to the structure of the database. If any copy of the
control file becomes corrupt, damaged, or unavailable, Oracle shut downs the
instance. If the control file is corrupt and Oracle has not already shut down, you
should issue the SHUTDOWN ABORT command. See “Shutting Down a
Database.”
Managing Databases and Instances
Oracle provides a number of different ways to create and manage databases on
many operating systems. This section describes how to create the Enterprise
eTIME database and instance on Windows NT and UNIX systems.
Creating the Enterprise eTIME Database on Windows NT
On Windows NT systems, use the NT Instance Manager to create the database and
instance. The NT Instance Manager provides both a command line interface and a
graphical interface.
Using the Command Line Interface
The command-line syntax to create an instance for a database called TKCS is:
ORADIMnn -NEW -SID tkcs
[-INTPWD <password>]
[-STARTMODE auto|manual]
[-PFILE pfile-location]
2-14
ADP, Inc.
Managing Components of an Oracle Database
The nn in the command name identifies the version of NT Instance Manager you
are using—ORADIM80 for Oracle8.0 and ORADIM for Oracle8i.
NEW specifies that you are creating a new instance. The NEW command creates
only the instance and associated files, such as the password file and control file.
SID specifies the new instance’s system identifier; this is the same as the SID in
the parameter file. These parameters are required.
INTPWD specifies a password for this instance’s INTERNAL account.
STARTMODE determines whether the instance services are started automatically
when the system starts or manually by the DBA.
PFILE specifies the location of the database’s parameter file (init*.ora). You need
the PFILE parameter only if your parameter file is not in the default
ORACLE_HOME\DATABASE directory or is not named initSID.ora.
To get a complete list of available commands, enter this command:
ORADIMnn -help
Enterprise eTIME Database Administrator’s Guide
2-15
Chapter 2
Managing Your Oracle Database
Using the NT Instance Manager Graphical Interface
The NT Instance Manager also provides a graphical interface.
1. Select Start > Programs > Oracle on Windows NT > NT Instance
Manager.
2. Click the New button.
3. Enter the requested information, then click Advanced. The Advanced
Parameters window opens. Be sure to fill in the correct database identifier.
This name defaults to ORACLE; if you forget to change it, you receive an
error that the database names do not match and you must start over.
The NT Instance Manager creates the database and runs the scripts that create the
data dictionary. This process can take several minutes.
Creating the Database
To manually create the database if you did not use Instance Manager, you need to
perform these tasks:
1. If it is not already started, start the instance without mounting a database.
2. Create the database using the CREATE DATABASE statement with the
options listed in the Enterprise eTIME Database Installation Guide.
a. Run the SQL script CATALOG.SQL to create the data dictionary.
b. Run CATPROC.SQL.
c. Log on as SYSTEM and run $ORACLE_HOME\dbs\pupbld.
2-16
ADP, Inc.
Managing Components of an Oracle Database
3. Before you can access the newly created database from a client, you must set
up the network communications software and utilities. The Oracle networking
interface is called NET*8. Consult the Oracle documentation for your
operating system and version for how to set up the listener file, the TNS alias,
and the Open Database Connectivity (ODBC) driver.
4. After you create the database, you can create the other database objects. See
“Managing Tablespaces and Datafiles.”
Fixing Common Errors
You can receive and correct the following common errors:
If you receive Error ORA-09352, “Windows 32-bit Two-Task driver unable to
spawn new ORACLE task,” it means that the services for the newly created
instance have not been started. Select Control Panel > Services and start the
services named OracleStartSID and OracleServiceSID. If the error persists, make
sure you spelled the service’s name correctly.
If you are trying to start the instance from the Oracle Instance Manager, you might
receive error ORA-12154, “TNS: could not resolve service name.” This usually
means you did not configure the listener file or TNS alias correctly.
Creating the Enterprise eTIME Database on UNIX
To create the Enterprise eTIME database and instance on UNIX, use the Server
Manager utility. Follow these steps:
1. From the operating system prompt, set your ORACLE_SID and
ORACLE_HOME shell variables.
2. Start Server Manager by entering the following command at the operating
system prompt:
$ORACLE_HOME/bin/srvmgr
Enterprise eTIME Database Administrator’s Guide
2-17
Chapter 2
Managing Your Oracle Database
3. In Server Manager, enter the following commands:
connect internal
spool $ORACLE_HOME/dbs/create_SID.log
startup nomount pfile=$ORACLE_HOME/dbs/
initSID.ora
4. Create the database by using the CREATE DATABASE statement with the
options listed in the Enterprise eTIME Database Installation Guide.
5. Enter the following commands to create the data dictionary information:
@$ORACLE_HOME/rdbms/admin/catalog.sql
@$ORACLE_HOME/rdbms/admin/catproc.sql
connect system/manager
@$ORACLE_HOME/rdbms/admin/catdbsyn.sql
@$ORACLE_HOME/sqlplus/admin/PUPBLD.SQL
6. Create the necessary tablespaces, users, and roles, as explained in the
installation guide.
7. In Server Manager, enter the following command:
spool off
8. Before you can access the newly created database from a client, you must set
up the network communications software and utilities. The Oracle networking
interface is called NET*8. Consult the Oracle documentation for your
operating system and version for how to set up the listener file, the TNS alias,
and the ODBC driver.
2-18
ADP, Inc.
Managing Components of an Oracle Database
Finishing Database Creation
After you create the Enterprise eTIME database, or any production database, you
should immediately perform these tasks:
1. Set the database to ARCHIVELOGMODE if you did not specify that option
when you created the database. See “Archived Redo Logs and
ARCHIVELOGMODE.” Enterprise eTIME does not require
ARCHIVELOGMODE, but without it you cannot recover changes made
between complete backups.
2. Shut down the database using the NORMAL option. See “Shutting Down a
Database.”
3. Back up the database, as described in “Backup Procedures.”
4. Start the database for normal operations, as described in the next section.
Starting a Database
Oracle lets you start a database in any of three different modes:
w
The database can be opened for normal use. Oracle makes the database
available for normal operation.
w
The instance can be started without opening the database. Oracle starts the
database instance by reading the parameter file (see “Managing Parameter
Files”) to determine the location of the control file, characteristics of the
instance, and other information about the physical structure of the database. It
uses this information to allocate the System Global Area and start the
background processes.
You start the instance without opening the database when you are creating the
database and for certain administrative procedures.
w
The database can be mounted but not open. This is called restricted mode.
Oracle associates the database with the instance by reading the control file.
This is called mounting the database.
At this point, the database administrator can rebuild indexes, import or export
database objects, load large amounts of data through SQL*Loader, and so on.
Users who do not have DBA rights in the database receives an error message
when they try to connect.
Enterprise eTIME Database Administrator’s Guide
2-19
Chapter 2
Managing Your Oracle Database
Note
You can also put an open database in restricted mode.
The following sections explain how to start the database in each mode.
Starting a Database for Normal Use
Use the following Server Manager command to start a database:
STARTUP [PFILE = file] [OPEN] [dbname]
You must be connected to the instance as INTERNAL, SYSOPER, or SYSDBA.
PFILE specifies the name of the parameter (init*.ora) file to use. OPEN opens the
database for normal use. If you specify STARTUP with no parameters, Oracle
uses the standard parameter file to open the default database for normal use.
You should perform all startups and shutdowns from the Server Manager on
UNIX. For Oracle on Windows NT, you can also start the database from the NT
Instance Manager. To start an instance, specify the following parameters:
-STARTUP -SID <sid>
-PFILE <filename>
[-USRPWD <user_pwd>]
-STARTTYPE <SRVC,INST>
SID and PFILE are the same as in the Server Manager command. USRPWD
specifies the password for the user’s account. STARTTYPE requests that Oracle
start either the services, the instance, or both.
The instance does not start unless the Windows NT services that support the
database are started. See “Fixing Common Errors.”
Starting a Database in Restricted Mode
Use the following Server Manager command to start a database without opening
it:
STARTUP [PFILE=file] MOUNT [dbname]
2-20
ADP, Inc.
Managing Components of an Oracle Database
If the database is already open, you can put it into restricted mode using the
following SQL command:
ALTER SYSTEM ENABLE RESTRICTED SESSION;
Starting an Instance Without Mounting a Database
Use the following Server Manager command to start the database instance without
opening or mounting the database:
STARTUP [PFILE=file] NOMOUNT [dbname]
Shutting Down a Database
Shutting down reverses the steps of opening the database. Oracle closes the
database, dismounts it, and shuts down the instance. Users who attempt to connect
while the database is shutting down receive a message informing them that a
shutdown is in progress, and connection is not permitted.
The Server Manager syntax to shut down a database is:
SHUTDOWN [NORMAL|IMMEDIATE|ABORT]
NORMAL means no new connections are allowed, but connected users can
continue. When all users have disconnected, the database is brought down. This
can take some time if, for instance, an interactive user has gone away and left a
session connected. NORMAL is the default.
IMMEDIATE disconnects user sessions immediately, rolls back all uncommitted
transactions, and closes and dismounts the database.
ABORT shuts the database down as quickly as possible. It stops the instance
without rolling back uncommitted transactions. When the database starts next
time, you need to use instance recovery (see “Instance Recovery”).
Caution
Use the ABORT function only in extreme circumstances because uncommitted
transactions are not rolled back. This could result in your data being in an
inconsistent state.
Enterprise eTIME Database Administrator’s Guide
2-21
Chapter 2
Managing Your Oracle Database
Server Manager allows multiple simultaneous connections. Disconnect all but one
such session before you issue a SHUTDOWN NORMAL command. Otherwise,
your own connections prevent the database from shutting down.
Managing Tablespaces and Datafiles
Tablespaces divide an Oracle database into logical units. The logical data is stored
in a physical file called a datafile, identified by a file specification that follows the
conventions of your operating system.
If possible, you should place each tablespace for the Enterprise eTIME database
on a separate disk and multiplex the online redo logs across separate disks. The
installation guide describes how to distribute the tablespaces across disks.
The next sections show how to create the additional tablespaces needed by the
Enterprise eTIME database. For more information, see the Enterprise eTIME
Database Installation Guide.
About Segments and Extents
A segment is a collection of extents allocated for a specific type of data structure,
such as a table or an index. Oracle uses four kinds of segments:
w
Data segments hold data. Each non-clustered table has one data segment.
Each cluster has one data segment that holds data for every table in the cluster.
w
Index segments hold the index information for a table.
w
Rollback segments store information about every data change that is made in
the database.
w
Temporary segments provide work space for SQL commands that need a
place to write calculations and the results of other operations. These extents
are returned to the database as soon as the statement completes.
Each segment in a database has at least one extent, the initial extent. Rollback
segments have at least two extents. These extents are all stored in the same
tablespace, but can be on different datafiles within that tablespace.
2-22
ADP, Inc.
Managing Components of an Oracle Database
Oracle creates and manages data, index, and temporary segments and extents.
When a segment needs more space, Oracle allocates a new extent. This new extent
is called an incremental extent. The default storage clause for the tablespace or the
table determines the size of the extent.
About Data Blocks
The data block is the smallest unit of an Oracle database. Its format is the same no
matter what kind of segment it is in.
w
The block header includes the block address, the tables that have inserted
rows into the block, and how much space is available in the block.
w
A portion of the block stores the rows that contain the data.
w
Oracle reserves free space to hold rows that grow when they are modified (for
example, when a value is supplied for a previously null field). See
“Performance and Tuning” for more information about data block size.
Block header
Free space
Empty space into which
rows can be inserted
Stored rows
Enterprise eTIME Database Administrator’s Guide
2-23
Chapter 2
Managing Your Oracle Database
Creating Tablespaces
Creating the Rollback Tablespace
Before you can create tablespaces or other database objects, the database must
contain at least two rollback segments. Only one, the system rollback segment, is
created by default.
To create the rollback tablespace for the Enterprise eTIME database, follow these
steps:
1. Create a second rollback segment in the system space:
SQL> CREATE PUBLIC ROLLBACK SEGMENT temp_rbs;
2. Alter it to place it online:
SQL> ALTER ROLLBACK SEGMENT temp_rbs ONLINE;
3. Create the rollback tablespace that the Enterprise eTIME database uses. Use
the following SQL statement to create the rollback tablespace:
CREATE TABLESPACE rollback-ts
DATAFILE ‘datafilespec’
SIZE 5M;
Give the rollback tablespace a name that makes sense in your environment.
The datafilespec is a complete file specification that is valid according to the
rules of your operating system. The datafile should not be on the same disk as
any data tablespace.
SIZE 5M specifies the tablespace’s disk allocation in Megabytes; you can also
specify Bytes or Kilobytes. You can specify a different value if you want a
larger tablespace. Use whatever allocation makes sense in your environment.
2-24
ADP, Inc.
Managing Components of an Oracle Database
4. Use the following SQL statements to create the rollback segment and make it
ready for use:
CREATE ROLLBACK SEGMENT r01 TABLESPACE rbs1;
ALTER ROLLBACK SEGMENT r01 ONLINE;
Give the Enterprise eTIME rollback segments any name that makes sense in
your environment. Your database’s usage determines how many rollback
segments you need. Oracle suggests that generally each rollback segment
supports four user processes. For large, active databases, you can add more
rollback segments or make the segments larger.
5. After you create the rollback segments, place the rollback tablespace online:
ALTER TABLESPACE rbs1 ONLINE;
6. Alter the temporary system rollback segment to take it offline. You can then
delete temp_rbs, or leave it so it can be quickly placed online in an
emergency.
7. To make sure the rollback segments are brought online each time the instance
is started, add the following line to your init.ora file:
rolback_segments=(r01, r02,...)
Creating Data Tablespaces
The Enterprise eTIME database requires several tablespaces for data. The first
three tablespaces must be named tkcs1, tkcs2, and tkcs3. Other Enterprise eTIME
applications require additional tablespaces, as explained in the installation guide
for that product.
Use the following command to create the data tablespaces:
CREATE TABLESPACE TKCSn
DATAFILE ‘datafilespec’
SIZE 1024M
DEFAULT STORAGE (INITIAL 400K NEXT 400K
MINEXTENTS 1
MAXEXTENTS 121
PCTINCREASE 0);
Enterprise eTIME Database Administrator’s Guide
2-25
Chapter 2
Managing Your Oracle Database
The n in TKCSn represents the number of the Enterprise eTIME tablespace you
are creating.
DEFAULT STORAGE specifies the storage characteristics of tables or other
objects created in the tablespace if the SQL command that creates them does not
specify other values.
The SIZE and DEFAULT STORAGE values should make sense for your
installation. The installation guide tells how to determine the values of the SIZE
and DEFAULT STORAGE parameters.
Creating the Temporary Tablespace
The Enterprise eTIME database requires a separate temporary tablespace. Use the
following command to create it:
CREATE TABLESPACE temp
DATAFILE ‘tempfilespec’ TEMPORARY;
The temporary tablespace does not need to reside on its own disk and it can have
any name that makes sense in your environment. You can specify
AUTOEXTEND or DEFAULT STORAGE clauses in the previous command for
any other tablespace. Use settings that reflect your anticipated needs. See the
Oracle documentation for the syntax.
Adding Datafiles to a Tablespace
The tablespace’s first datafile is created as part of the CREATE TABLESPACE
statement. To add more datafiles, use the ALTER TABLESPACE statement:
ALTER TABLESPACE tkcs1 ADD DATAFILE ‘datafilespec2’
SIZE 100M;
SIZE tells how much of the tablespace should be allocated to this tablespace.
You can add a datafile while the tablespace is online or offline. Additional
datafiles can be on the same disk, or on different disks. Specify AUTOEXTEND
in the previous command if you want the datafile to extend itself automatically
when it runs out of space. See the Oracle documentation for the syntax.
2-26
ADP, Inc.
Managing Components of an Oracle Database
Taking Tablespaces Offline
Oracle allows you to take individual tablespaces offline for backup, index
rebuilding, or other maintenance. While a tablespace is offline, users cannot
access it, but you can perform administrative tasks. You can even restore a datafile
or tablespace separately and recover it to be consistent with the rest of the
database. Users continue to access tables in other tablespaces normally.
Because the SYSTEM table contains the data dictionary, which the database
requires for its operation, you cannot take the SYSTEM tablespace offline.
In general, the Enterprise eTIME tables contain too many cross-table
dependencies to make this a useful thing to do, but you can find some
circumstances when it makes sense.
Enterprise eTIME Database Administrator’s Guide
2-27
Chapter 2
Managing Your Oracle Database
Managing Redo Log Files
The redo log files record every data change made to the database so changes can
be recovered after a failure. Information in the redo log entries can be used to
reconstruct all changes made to the database, including the rollback segments.
The redo logs include several components: the redo buffer in the system global
area, redo entries in the redo buffer, the online redo log files, and, optionally, the
archived redo log files.
Understanding How Online Redo Logs Work
In the database’s default NOARCHIVELOGMODE, redo logs work as follows:
1. For every change made to the database, Oracle writes a redo log entry to the
redo log buffer in the system global area. This entry does not correspond
directly to an operation as the user sees it but rather provides the internal
information Oracle needs to reconstruct the change the user made.
2. The LGWR background process (the log writer) writes the redo log entries to
the first empty redo log file, as shown in the following figure. This log is
called the current redo log.
.
LGWR
log 1
2-28
log 2
log 3
log 4
log 5
ADP, Inc.
Managing Redo Log Files
3. When one log file is full, LGWR uses the next log file. This is called a log
switch. (See “Log Switching.”) In the figure, Oracle has performed two log
switches: from log 1 to log 2, and from log 2 to log 3.
4. When the last log file is full, LGWR reuses the first file, writing over the old
redo log entries.
At this point, the database is no longer recoverable because necessary records
have been lost. If the database fails and has to be restored from backups, all
changes made since the last physical backup are lost. To make sure your
changes are recoverable, enable archiving, as explained in “Enabling
Archiving.” With archiving enabled, the LGWR process cannot reuse the
online redo log file until its contents have been copied to the archive area.
5. LGWR continues to cycle through the log files in the same manner as long as
the database is running.
Enterprise eTIME Database Administrator’s Guide
2-29
Chapter 2
Managing Your Oracle Database
Log Groups
A log group is a set of duplicate redo log files. Oracle calls these duplicate copies
of the log multiplexed or mirrored files.
When a change is written to one redo log in a group, the same change is written to
all other members of that group, as shown in the following figure:
LGWR
A
B
log group 1
log group 2
log group 3
log group 4
log group 5
Oracle cycles through log groups the same way it cycles through individual log
files: when one group is filled, it moves to the next available group. Log switching
is performed as for single log files. After Oracle fills the last group, it goes back to
the first group and reuses it; overwriting and archiving proceed as they do for
individual log files.
Log file groups are identified by number. All members of a group must be the
same size. All groups should have the same number of members, and the members
should be the same size across groups.
2-30
ADP, Inc.
Managing Redo Log Files
Each member of a log group should be on a separate disk from other members so
logging can continue even if a disk drive fails or goes offline. As long as LGWR
can successfully write to at least one member of the group, it writes to all
accessible members of the group as usual. For example, as you refer to the
previous figure, assume disk A must be taken offline for maintenance. Oracle
marks the first member as INVALID and continues writing to the other redo log
file on drive B.
Log Switching
A log switch takes place when Oracle stops writing to one redo log or log group
and starts writing to another. This can occur two ways:
w
Automatically, when the first log or log group is full
w
Manually, as the result of a command
Oracle assigns each log file a log sequence number each time it begins writing to
the file. The log file retains this number when it is archived. The next time Oracle
reuses the log file, it assigns a new sequence number. If archiving is enabled for
the log groups shown in the previous figure, the current log file has a log sequence
number of 3 the first time it is used, 8 the second time, 13 the third time, and so
on.
When Oracle applies the redo logs during recovery, it applies them in ascending
order by log sequence number.
If archiving is not enabled, the redo log file retains its sequence number as it is
reused. The contents change but the number does not.
Checkpoints
A log switch triggers a database checkpoint. This means that the DBWR process
writes all modified database buffers from the SGA to the disk, including both
committed and uncommitted data. The checkpoint guarantees that all data blocks
modified since the last checkpoint are written to disk.
Enterprise eTIME Database Administrator’s Guide
2-31
Chapter 2
Managing Your Oracle Database
The checkpoint must finish before the redo log file that triggered the checkpoint
can be reused. If log files fill up so fast that another log switch occurs before the
first checkpoint finishes, the first checkpoint stops and the second takes over.
The CKPT background process manages database checkpoints. CKPT records, in
the control file, the location of the next entry to be written to the online redo log
file, and then requests the DBWR process to start writing modified data to the
disk. DBWR performs the checkpoint at the same time that it continues other
database work, so a checkpoint in an active database with large memory caches
can take a long time to complete.
If the CHKPT background process is not started for the instance (through the
‘checkpoint_process=true’ line in the init.ora file), then the LGWR process
handles the checkpoints.
In addition to checkpoints at log switches, database checkpoints take place at
these times:
w
At intervals specified by the LOG_CHECKPOINT_INTERVAL and
LOG_CHECKPOINT_TIMEOUT parameters
w
When the database is shutting down with the NORMAL or IMMEDIATE
options
w
As the result of a command that explicitly triggers log switching
Some checkpoints apply only to tablespaces or datafiles. See the Oracle Backup
and Recovery Guide for details about all these options.
All online redo log buffers remain active until the checkpoint completes, and
LGWR continues to write to them. This means they are not written to the archive
area, and the LGWR process can run out of space. If this happens, the database
hangs until the checkpoint completes and online redo logs are released for LGWR
to reuse.
2-32
ADP, Inc.
Managing Redo Log Files
If your database hangs repeatedly, you can do one or more of the following to
make checkpoints complete more quickly:
w
Create more DBWR slave processes.
w
Use smaller values for the parameters LOG_CHECKPOINT_INTERVAL and
LOG_CHECKPOINT_TIMEOUT to cause more frequent checkpoints that
take less time to write.
w
Check the ARCH process. If it is not copying and releasing online redo
buffers quickly enough, it can be behind before the checkpoint starts.
Creating Online Redo Log Files and Log Groups
By default, Oracle creates two log groups, each containing a single redo log file.
In a production database, you should add at least one more redo log file to each
log group. You probably need to add more redo log groups as well. You can create
the additional redo log files and log groups when you create the database, or you
can add them later.
Place the redo logs on a separate disk from any data files. This reduces disk
contention and lowers the risk that a single failure destroys both data and the logs
Oracle needs to reconstruct the data.
If at all possible, your redo logs should be multiplexed (mirrored), as explained in
“Log Groups.”
Adding a Log File Group to an Existing Database
Use the following command using the Server Manager utility to add a log file
group:
ALTER DATABASE
ADD LOGFILE GROUP 10 (‘file1’, ‘file2’) SIZE 500K;
Use the full operating system path to the physical file where the log is stored. The
group number is an integer between 1 and MAXLOGFILES. Oracle recommends
that you not skip numbers (for example, do not use 10, 20, 30...) because it wastes
space in the control file.
Enterprise eTIME Database Administrator’s Guide
2-33
Chapter 2
Managing Your Oracle Database
Adding Redo Log Files to an Existing Log Group
If you want to add more redundancy to your database, or if log files have been lost
because of disk failure, you might need to add log files to an existing group. Use
the following SQL command using the Server Manager utility:
ALTER DATABASE
ADD LOGFILE MEMBER ‘log2b’ to GROUP 2;
Use the full operating system path to the physical file where the log is stored.
Dropping Redo Log Files or Log Groups
You seldom need to drop an entire group, but dropping an individual member
happens more often. For instance, if a disk goes bad, you need to drop that file and
re-create it when the disk becomes available again. Use the following SQL
commands using the Server Manager utility:
ALTER DATABASE DROP LOGFILE GROUP n;
ALTER DATABASE DROP LOGFILE MEMBER ‘FILE1’;
The ALTER DATABASE command removes the log file entry from the control
file. It does not remove the physical file from the disk. To remove the physical
file, use operating system commands to delete it.
You cannot drop the active group or a member of the active group. Force a log
switch first to make another file or group active (see the Oracle Database
Administrator’s Guide). Make sure the log file has been archived.
Viewing Information About Online Redo Log Files
The data dictionary views V$LOG and V$LOGFILE provide useful information
about the redo logs.
2-34
ADP, Inc.
Managing Redo Log Files
V$LOG view
The V$LOG view includes information about the redo log groups. The following
example shows the members of each group and indicates whether the member has
been archived:
SVRMGR> SELECT GROUP#, MEMBERS, SEQUENCE#, ARCHIVED
FROM V$LOG;
GROUP#
MEMBERS
SEQUENCE# ARC
--------- --------- --------- --1
1
21
NO
2
1
22
NO
2 rows selected.
V$LOGFILE view
The V$LOGFILE view includes information about the redo log files. The
following example shows the log files that are available in the Oracle sample
database immediately after it is created:
SVRMGR> SELECT * FROM V$LOGFILE;
GROUP#
STATUS MEMBER
---------- ------- ----------------------------------1
C:\ORANT\DATABASE\LOG2ORCL.ORA
2
STALE
C:\ORANT\DATABASE\LOG1ORCL.ORA
2 rows selected.
A blank STATUS field means the group is currently active. STALE means the log
file is not complete or correct. It becomes valid again the next time the group
becomes active. In the example above, the STALE log file has not yet been used.
A status of INVALID means Oracle cannot access the log file, perhaps because
the disk is offline or the file is damaged.
Enterprise eTIME Database Administrator’s Guide
2-35
Chapter 2
Managing Your Oracle Database
Specifics for the Enterprise eTIME Database
Create at least three redo log files (logs). The size depends on your database’s size
and activity; check the alert.ora file to monitor log switches to determine whether
you need to make your log files bigger. Oracle’s default size for redo log files is
200 KB, which tends to be small for a production database doing online
transaction processing.
Ideally, each archived log should fit onto one unit of archive storage (a single tape,
for example). It should also minimize wasted space. For example, if the log file
fills 35% of a tape, you can place only two archive logs on the tape, with 30% of
the tape wasted. It is usually best to make each log file slightly smaller, so that
three archive logs fit on the tape and tape changes happen less often. You could
also make the log files larger, so two archived logs fill the tape.
Configuration Parameters that Affect Redo Logs
MAXLOGFILES specifies how many log files or log groups you can create for
this database instance. The value you specify when you create the database can
never be changed without rebuilding the database, so make sure it is large enough
to accommodate your database’s future growth.
MAXLOGMEMBERS specifies how many members a log group can have. This
parameter also does not change. Its default value depends on the operating system
on which you are running. You can use the LOG_FILES parameter in the
parameter file to decrease the number of available log files, but you cannot
increase it to more than the value of MAXLOGFILES.
Archived Redo Logs and ARCHIVELOGMODE
Archiving an online redo log file means copying it to another location, where it
can be saved and reused in case the database has to be recovered. By default,
archiving is not enabled; the LGWR process reuses the redo log files as they are
filled, and the database is not recoverable. It can be restored from the last offline
backup of the physical files, but it cannot be brought up to date.
2-36
ADP, Inc.
Managing Redo Log Files
To have full backup and recovery capabilities available, your Enterprise eTIME
database should enable archiving.
Enabling Archiving
Enabling archiving is also called running in ARCHIVELOGMODE. Use the
following command to enable archiving:
ALTER DATABASE mydb ARCHIVELOGMODE;
The LGWR process still reuses the log files, but it waits until they have been
copied to another location for permanent storage. You can do this two ways:
w
Automatically, by specifying a LOG_ARCHIVE_DEST and
LOG_ARCHIVE_START in the parameter file or using the SQL command
ALTER SYSTEM ARCHIVE LOG START ‘destination’. This starts
the ARCH process, which performs automatic archiving.
w
Manually, by entering the SQL command ALTER SYSTEM ARCHIVE LOG
log-group TO destination.
If you archive manually, online redo logs are not be reused until you issue the
archive command; if the database runs out of online redo log space, it hangs. ADP
recommends archiving automatically.
Whether you use automatic or manual archiving, the redo log files are copied to
another device, called the archive area or archive destination. For automatic
archiving, you specify the archive destination with the LOG_ARCHIVE_DEST
parameter in the parameter file. The LOG_ARCHIVE_DUPLEX_DEST
parameter lets you specify a second destination for the archive operation, thus
mirroring the archive.
One common archiving strategy points LOG_ARCHIVE_DUPLEX_DEST to a
network drive where the archived redo logs are copied to permanent tertiary
storage, while LOG_ARCHIVE_DEST specifies a local disk where the logs are is
available for quick recovery. The local backups are typically kept for only a short
period.
Enterprise eTIME Database Administrator’s Guide
2-37
Chapter 2
Managing Your Oracle Database
Understanding How Automatic Archiving Works
After the LGWR process writes the redo log entries to an online redo log file and
completes the log switch, the ARCH process copies the completed log to the
archive area. LGWR cannot reuse the filled online log until its contents have been
archived.
The following figure shows a database that archives log files directly to a tape
device. Archiving directly to a disk device follows the same process. Log 1 to log
5 can be either log groups or individual log files.
LGWR
log 1
log 2
log 3
log 4
log 5
ARCH
Tape drive
Automatic archiving occurs as follows:
1. LGWR fills log 1 and switches to log 2.
2. After the log switch completes, ARCH begins to write log1 to the tape drive.
3. While the archiving operation is still in progress, LGWR fills log 2 and
switches to log 3. Log 2 is now ready to be archived. LGWR cannot reuse it
until its contents are archived.
4. LGWR can reuse log1 as soon as the archiving operation finishes.
2-38
ADP, Inc.
Managing Redo Log Files
Notice that LGWR has filled log 2 and half of log 3 while ARCH is still writing
log1 to the tape drive. If the database is active sporadically and ARCH has time to
catch up, this can be acceptable. However, if LGWR fills all the logs before log 1
is archived, LGWR must wait until log 1 is available, and the database hangs until
the archiving operation completes.
To clear the database, you can manually archive the waiting logs to a different
area. Possible long-term solutions include:
w
Archive to a disk drive, and then copy the archived logs to the tape device.
w
Add more logs.
w
Make the individual log files larger.
Enterprise eTIME Database Administrator’s Guide
2-39
Chapter 2
Managing Your Oracle Database
Backup Procedures
A physical backup copies the files that make up the database instance. The copy
exactly duplicates the on-disk bits and bytes of the files, but does not contain any
information about the instance or the relational structures within the database.
A logical backup copies the information needed to reconstruct all or part of the
contents of the database. It can include the metadata, the data, or both.
In Oracle, the physical backup must include all the files the database and instance
need to start up and run: control files, parameter files, datafiles, redo log files, and
any other external files your database uses. Logical backups can contain data and
data definitions for all or part of the database.
In most situations, a combination of physical and logical backups provides the
best coverage for recovering from a range of potential failures. The following
sections describe some of the more commonly used backup features. You should
consult the Oracle documentation for your version and operating system,
particularly the Oracle Backup and Recovery manual, before you decide on your
backup strategy.
See “Recovering and Restoring Damaged Databases”for information about how
to restore from physical and logical backups of your database.
Performing Physical Backups
A full physical backup of the database, combined with online and archived redo
log files, guarantees that all committed transactions can be recovered after disk or
system failure. Oracle supports both online (“hot”) and offline (“cold”) backups of
the database files.
2-40
ADP, Inc.
Backup Procedures
Making Offline (“Cold”) Backups
To perform an offline backup:
1. Shut the database down normally.
2. Use operating system commands or a third-party utility to copy all the
physical files in your database to a backup device. This can be accomplished
as part of a regular disk backup or a separate backup of only the database files.
The resulting set of files is called a consistent whole backup in the Oracle
documentation.
3. Restart the database for normal operation.
4. Back up all of the following files:
w
The control files. While the database is shut down, you can use operating
system commands.
w
All parameter files associated with the database (init.ora, config.ora).
w
All datafiles.
w
The online redo logs. (The ALTER SYSTEM ARCHIVE ALL command
in SQL archives all full redo logs when you start the backup; this can
speed backup and restore.)
w
The password file, if your site uses it.
w
All archived redo log files, if you are running in ARCHIVELOGMODE.
In ARCHIVELOGMODE, you can perform a whole database backup a
piece at a time. For example, if you back up tablespace tkcs1 and the
control file on the first night, tkcs2 and the control file the second night,
and so on, at the end of the week you have a whole database backup of
your Enterprise eTIME database. The archived redo logs can be applied
to make the database fully consistent.
Enterprise eTIME Database Administrator’s Guide
2-41
Chapter 2
Managing Your Oracle Database
Making Online (“Hot”) Backups
If your database runs in ARCHIVELOGMODE, you can perform a physical
backup of your database without shutting it down. Use operating system
commands or a third-party utility to copy all the physical files in your database to
a backup device. This is called an inconsistent whole backup, because parts of the
database are being modified and written to disk while the files are being copied.
To back up an individual tablespace, follow these steps:
1. Put the tablespace in backup mode using this SQL command:
ALTER TABLESPACE BEGIN BACKUP
2. Physically back up the tablespace’s data files using operating system
commands or a third-party utility.
3. Return the tablespace to normal operations:
ALTER TABLESPACE END BACKUP
Since the control file is always in use when the database is open, you must back it
up separately. You should back it up under these circumstances:
w
Whenever you make a whole database backup
w
Whenever you alter the structure of the database
Use the following SQL command to back up the control file:
ALTER DATABASE BACKUP CONTROLFILE TO ‘location’;
Note that location is the same device to which the rest of the backup was made.
In an emergency, you can also make an inconsistent whole database backup after a
system crash or a shutdown with errors, or after the ABORT option. Oracle
recommends that you not use inconsistent closed database backups, but in some
emergencies it might be your only option.
Apply the archived redo logs to bring the database back to a consistent state. Note
that you cannot use inconsistent backups if you do not save all your archived redo
log files; Oracle does not have the information it needs to synchronize the
inconsistent files.
2-42
ADP, Inc.
Backup Procedures
Performing Logical Backups
A logical backup copies a part of the data in the database, including the
information that is required to reconstruct it. This information includes table and
index definitions, storage defaults, and so on.
Using the Export Utility for Backups
The main method for logical backup is the Export utility. The Export utility copies
both data and data definitions to an operating system file in binary format:
w
If you have SQL*NET or NET*8, you can write this file to a device on
another system on the network.
w
You can use FTP or other file copy protocols to copy the export file across
systems.
w
You can copy the export file to tape for storage.
w
You can use the Import utility to restore lost data into the current database or
to copy data to another database.
Export is performed on a running database. You can export all or part of the
database:
w
Specific tables
w
All objects belonging to a specified user’s schema
w
The full database
The full database export includes all objects in the database except those
belonging to SYS. Those objects are not needed because the bare-bones
database already includes them.
Export generates in binary form all the commands needed to re-create the
exported objects.
Enterprise eTIME Database Administrator’s Guide
2-43
Chapter 2
Managing Your Oracle Database
If you are exporting the full database, you have three options for how much of the
database to export:
w
Complete is similar to a full database backup. It copies everything in the
database, updates tables used to track incremental and cumulative exports,
and provides a baseline for incremental and cumulative backups.
w
Cumulative copies only those tables changed since the last cumulative or
complete export. It copies table definitions and all data, not just the changed
data–if only one row has been modified, the entire table is exported.
w
Incremental copies only those tables changed since the incremental,
cumulative, or complete export. As with a cumulative export, if any row in a
table has changed, the entire table is exported.
After a complete export, you no longer need to retain previous cumulative or
incremental backups; the complete backup includes all the information contained
in the previous backups. After a cumulative backup, you can discard previous
incremental backups.
Specifying Export Characteristics
Create a parameter file containing the options for your export. You can give this
file any name you want; the name and structure of the file should follow the rules
for your operating system. This file contains a list of parameters and values.
For example, a file named tkcsfull.par that contained the following parameters
would perform a full export to a file named TKCS_BACKUP.DMP on the default
device:
FULL=Y
INCTYPE=INCREMENTAL
FILE=TCKS_BACKUP.DMP
GRANTS=Y
INDEXES=Y
CONSISTENT=Y
2-44
ADP, Inc.
Backup Procedures
FULL=Y specifies a full database export, while INCTYPE=INCREMENTAL
causes only those tables that have changed since the last incremental, cumulative,
or complete export to be copied. You cannot use FULL=Y if you specify a user.
FILE=filename identifies the output file. The default extension is .DMP, but you
can give it any name you want. If you use SQL*NET or NET*8, you can write the
export file directly to another Oracle server.
GRANTS=Y and INDEXES=Y means that these objects are exported along with
the objects to which they apply.
CONSISTENT=Y requests that Oracle treat the export as a read-consistent
transaction. This means that the export reflects the state of the database at the time
the export began. You should use CONSISTENT=Y if other users are updating
the part of the database you are exporting, but keep in mind that the entire export
is considered a single transaction, and occupies a rollback segment for the
duration of the transaction. For that reason, consider exporting the tables that
require consistency in one transaction and exporting the rest of the tables at a time
when their tablespace can be taken offline.
You can have different parameter files for different kinds of export. For example,
the previous code might be contained in a file named tkcsincr.par, while another
file named tkcsall.par specifies the parameters for a full database export
(INCTYPE=COMPLETE).
You do not need to include any parameters that you do not use, or for which you
accept the default values. However, some defaults are specific to the database, the
system, or the operating system. If you export and import across databases or
operating systems, it is a good idea to specify all parameters so you get the results
you want, even if a default changes.
All users with CREATE SESSION rights can export their own tables. To export
objects contained in another user’s schema, you must have the role
EXP_FULL_DATABASE granted to you. This role is granted to all DBAs.
The Oracle Utilities manual explains all the Export parameters in detail.
Enterprise eTIME Database Administrator’s Guide
2-45
Chapter 2
Managing Your Oracle Database
Running the Export Utility
To run the Export utility, follow these steps:
1. Make sure you have enough space for the export on the device to which you
write the export file. Export returns an error and stops if it runs out of space.
To estimate how much space you need, you can use this SQL statement to
determine the total disk usage for all tables in the database:
SELECT SUM(BYTES) FROM DBA_SEGMENTS
WHERE SEGMENT_TYPE=’TABLE’;
2. Specify the parameter file as input to the Export utility. The following
example shows a command that would run the tkcsfull.par file explained in
the previous section:
exp username/password PARFILE=tkcsfull.par
You can enter the parameters on the command line, but Oracle recommends
using the parameter file. For Oracle NT, the exact name of the Export utility
vary according to the Oracle version you are using: EXP80 for Oracle8 or
EXP81 for Oracle 8i.
To access online Help, enter:
exp help=Y
3. To export the entire Enterprise eTIME schema, export with the option
USER = tkcsowner.
Transferring Export Files Across Operating Systems
You can copy an export file to another operating system using FTP or another file
transfer protocol that can handle binary format files.
Character set translation and other conversion can take place when you create the
export file and when you import it on another system. See the Oracle Utilities
guide for details.
2-46
ADP, Inc.
Backup Procedures
Performing Partial Backups
If a portion of your database is more active than the rest, you can perform more
frequent backups of heavily used tablespaces. SYSTEM and rollback tablespaces
can also be candidates. In event of a failure that requires restoration or recovery,
you have a more recent copy of the more active tablespace and fewer changes
must be applied from the redo logs, making recovery faster.
If You Run Out of Redo Log Space
If your database runs with archiving enabled, an online redo log cannot be reused
until its contents have been archived, either automatically or manually. If the last
redo log file fills up before the first is archived, the database hangs until the
ARCH process releases the next redo log.
To make sure you do not run out of redo log space, do one or more of the
following:
w
Add more redo log groups to give LGWR more buffers to work with.
w
Create additional slave processes for the ARCH process to make archiving go
faster.
w
If you are archiving directly to a slow tape drive or other slow device,
consider archiving to a disk area and then copying the online redo logs to tape
from the archive area.
w
Make sure that the online redo log files and the archive area each have a disk
for their exclusive use. This prevents ARCH and LGWR from slowing each
other down by contending for resources.
If You Lose a Redo Log Group
If you lose an entire online redo log group, all log file entries after the failed log
are useless. You should immediately make a full backup of the database. If you
lose an archived redo log group while you are recovering a database, recovery
cannot continue unless you can restore the archived redo log from another source,
such as a backup of the archive area. If you can recopy the redo log, recovery can
proceed as usual. Otherwise, you cannot restore past the point of the missing log.
Enterprise eTIME Database Administrator’s Guide
2-47
Chapter 2
Managing Your Oracle Database
If You Run Out of Archive Log Space
If the archive log space fills up, the ARCH process does not have room to copy
the next online redo log file and cannot be able to release the redo log for reuse.
When LGWR fills up all the online redo logs, the database hangs. The same thing
happens if the device containing the archive area goes offline.
Getting Your Database Back
To clear the online redo logs, manually archive them to an alternate location,
using the following SQL command:
ALTER SYSTEM ARCHIVE LOG CURRENT
TO ‘alternate location’;
You must have the OSDBA or OSOPER role granted to you. The DBA role in
Oracle on UNIX includes this role.
This statement overrides the archive destination specified for automatic archiving
in the LOG_ARCHIVE_DEST parameter, but it does not change the default
destination. Automatic archiving resumes to the same destination. If the archive
area is still full, the database hangs again as soon as all the online redo logs are
full. You must determine the reason for the failure and correct it before automatic
archiving to this destination works again.
While you are locating and correcting the problem, you can either:
w
Change the destination for automatic archiving. You can use either of two
techniques:
–
In the parameter file, specify a new value for the LOG_ARCHIVE_DEST
parameter, then stop and restart the database.
–
If you cannot stop and restart the database, use this SQL command:
ALTER SYSTEM ARCHIVE LOG START ‘alternate-dest’;
You should still change the LOG_ARCHIVE_DEST in the parameter file
so that the database restarts correctly in case of a failure.
2-48
ADP, Inc.
Backup Procedures
w
Archive manually until the archive area is available. Use the following
commands to stop the automatic archiving and archive by hand:
ALTER SYSTEM ARCHIVE LOG STOP;
ALTER SYSTEM ARCHIVE LOG CURRENT TO ‘alt-dest’;
To resume automatic archiving after the archive area is available, use the
following command:
ALTER SYSTEM ARCHIVE LOG START;
Long-Term Solutions
If you continue to run out of archive space, you might need to investigate any or
all of these options:
w
Archive to a larger disk.
w
Make sure the ARCH process is the only process writing to the archive disk.
w
Copy older archived redo logs to tape or other secondary storage, then delete
them from the archive area.
w
Perform full or incremental backups more often, reducing the number of
archived redo logs you need to keep.
Enterprise eTIME Database Administrator’s Guide
2-49
Chapter 2
Managing Your Oracle Database
Recovering and Restoring Damaged Databases
Before a database can be opened, all the files must be available and accessible,
and the contents must be in a consistent state. If files are missing, corrupt, or
otherwise inaccessible, the database needs to be partially or totally restored.
Oracle distinguishes between recovery and restoration. You restore a copy of a
file by copying it from a backup medium or reconstructing it from other
information. You recover a file when you apply redo logs to bring the file to a
consistent point in time relative to the other database files.
Oracle also distinguishes between instance recovery, which happens
automatically after most forms of system crash, and media recovery, which takes
place after you restore one or more missing files. Though the details vary, the
process is essentially the same: the contents of redo logs and rollback segments
are used to bring the database back to a consistent state.
Instance Recovery
Instance recovery restores a database to its transaction-consistent state just before
instance failure. This recovery takes place automatically whenever the database
opens after a system crash, instance failure, or SHUTDOWN ABORT, provided
no data or files were lost.
Remember that Oracle writes data blocks from the SGA to the disk only when
necessary. When it does need to write to the disk, it selects the disk blocks that
have not been used recently. These blocks might belong to an uncommitted
process, or might contain data that was later modified by a committed process.
Oracle can use the redo and rollback information to return the proper information
to a user query. However, if the instance fails, the database is left in an
inconsistent state:
2-50
w
Some data blocks modified by committed transactions appear only in the redo
logs, not in the datafiles to which they belong. These modifications must be
added to the database.
w
Some modified data blocks that were later rolled back can have been written
to the disk. These modifications must be removed from the database.
ADP, Inc.
Recovering and Restoring Damaged Databases
To bring the database back to a consistent state, Oracle follows these procedures:
w
Applies all changes recorded in the redo logs since the last incremental
checkpoint (rolls forward). Every change to data, index, or rollback segments
is reapplied and the rollback segments are re-created.
w
Opens the database for general use as soon as the cache recovery is complete.
Any data not locked by unrecovered transactions is available.
w
Marks all transactions that were active at the time of the failure as DEAD.
This means that if a new transaction needs a resource locked by the dead
transaction, the new transaction can immediately use the resource without
waiting until SMON finishes removing the old transaction.
w
Marks the rollback segments containing the dead transactions as “partly
available.”
w
SMON recovers the dead transactions, using the information in the rollback
segments to remove the uncommitted data (roll back).
When Instance Recovery Is Not Enough
You generally must restore files lost due to media failures, natural disasters, and
so on. You might also need to restore files when you upgrade disks or perform
other kinds of system maintenance that require dropping and re-creating objects.
You should always back up your database before you start such operations.
In most cases, you need to recover the restored files to make them consistent with
the rest of the database. (The only exception is if you are restoring the entire
database from a single closed database backup and leaving the database at that
point in the past. You might need to do this if the entire system was destroyed, the
database has become hopelessly corrupt, or the archived redo logs have been
destroyed or corrupted, or if you do not use ARCHIVELOGMODE.)
Frequently, a file is missing only temporarily: the disk on which it resides is being
repaired or upgraded, or has been accidentally taken offline, or a network
connection has failed. However, if the loss is permanent, you need to restore the
file or files from the physical backups. You can restore anything from a single file
to the entire database.
Enterprise eTIME Database Administrator’s Guide
2-51
Chapter 2
Managing Your Oracle Database
Use the commands appropriate to your operating system to copy or otherwise
restore the files to the proper location. If you use a third-party utility to make your
physical backups, you might also be able to use that utility to restore from the
backup.
Once the files are in place, you must bring them up to date so they are consistent
with the rest of the database. Oracle calls this media recovery. Recovering the
restored files brings them back to a consistent state by applying as many archived
and online redo logs as necessary.
Recovering Datafiles or Tablespaces
Use the following SQL command to initiate recovery of one or more datafiles:
ALTER DATABASE RECOVER DATAFILE ‘file1’, ‘file2’...;
To initiate recovery of one or more tablespaces, use the following command:
ALTER DATABASE RECOVER TABLESPACE ‘ts1’, ‘ts2’...;
Oracle recovers all datafiles in the tablespace; it returns an error if none of the
files requires recovery.
When you recover datafiles or tablespaces, the database itself can be closed or
open as long as the datafile or tablespace is offline. If the database is closed and
mounted EXCLUSIVE, the datafile or tablespace can be online or offline.
Recovering the Entire Database
If you need to recover the entire database, use the following command:
ALTER DATABASE RECOVER AUTOMATIC;
The database must be closed. Oracle recovers all online datafiles that require it. If
the instance shut down cleanly, and no files were restored from backups, recover
returns an error indicating that no recovery is required.
Recovery fails if any datafile is locked by another user.
2-52
ADP, Inc.
Recovering and Restoring Damaged Databases
Determining Which Files to Recover
The data dictionary view V$RECOVER_FILE lists all files that need to be
recovered and the problem that causes the need for recovery. It is useful only if
your control file is still intact. A restored or re-created control file does not
contain all the information Oracle needs to fill in V$RECOVER_FILE accurately.
To display the information from V$RECOVER_FILE, use the following SQL
statement:
SELECT FILE#, ONLINE, ERROR FROM V$RECOVER_FILE;
The command shown above tells you whether each datafile is online or offline and
what error, if any, it is returning. The table V$DATAFILE tells you which datafile
name is associated with FILE#. If V$RECOVER_FILE does not exist, no files
need recovery.
Applying Redo Logs
Oracle generates suggested file names based on the current values of the
LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization
parameters. To accept the suggested file name, use the following statement:
ALTER DATABASE RECOVER CONTINUE DEFAULT;
If you want to specify that the archived log files are to be read from a different
location other than the one that is currently specified by LOG_ARCHIVE_DEST,
use the following command:
ALTER DATABASE RECOVER AUTOMATIC FROM ‘alt-location’;
Server Manager does not support the FROM ‘alt-location’ clause. Therefore, do
not issue the command shown above from the Server Manager utility.
If you do not want Oracle to generate and suggest file names for the archived logs,
omit the AUTOMATIC parameter. You have to supply the correct name of each
log file in the sequence in an ALTER DATABASE RECOVER LOGFILE
statement:
ALTER DATABASE RECOVER LOGFILE ‘filename.arc’;
Enterprise eTIME Database Administrator’s Guide
2-53
Chapter 2
Managing Your Oracle Database
Determining Which Recovery Strategy to Use
The kind of restoration and recovery you need to perform depends on what
happened to your database and what files were damaged.
The strategies below assume that you automatically archive your redo logs,
multiplex your control files and redo log files, and perform periodic wholedatabase backups, as explained in this chapter. The Oracle Backup and Recovery
guide explains your options for other situations.
All Database Files Are Intact
If all files making up the database are still intact after the failure, as is usually the
case after a system crash, failure of a server process, power failure, instance
failure, and so on, you should perform the following steps to recover the database.
1. If Oracle has not already done so, shut down the database. If a background
process has failed, use SHUTDOWN ABORT.
2. When the problem has been corrected, restart the database.
3. Oracle automatically recovers the database.
All committed changes are saved. Work that was in progress at the time of the
failure needs to be re-entered. See “Instance Recovery.”
Temporary Loss of One or More Files
Events such as disk maintenance or repair can cause one or more database files is
to be unavailable temporarily. Your strategy depends on which file is unavailable.
w
The current control file—Oracle shuts down the database as soon as it tries
to write to the control file. Correct the problem and restart the database.
If the disk is unavailable for some time, you can edit init*.ora to point to one
of your alternate control files, then restart the database using the alternate
control file.
w
2-54
Datafile in SYSTEM tablespace—Oracle shuts down the database, because
the information in the SYSTEM tables is necessary for ordinary operation.
Correct the problem and restart the database.
ADP, Inc.
Recovering and Restoring Damaged Databases
w
Datafile in user tablespace—For read operations, Oracle returns an error, but
the database continues. When a write operation (including the checkpoint
write to the file header) fails, Oracle returns an error in the DBWR trace file
and takes the datafile offline.
When this occurs, perform the following steps:
a. Take the datafile offline if Oracle has not already done so. The rest of the
database remains available.
b. Correct the problem.
c. Bring the datafile back online.
w
Redo log file—If you use log groups, losing a member of the group generally
has no significant impact. If the member is missing for any length of time, you
should drop the missing file and add a replacement file in another location
until the device returns.
w
Archive area—Specify an alternate location for archiving. Do one of the
following:
–
Stop automatic archiving (Server Manager ARCHIVE LOG STOP) and
archive manually (Server Manager ARCHIVE LOG NEXT or ARCHIVE
LOG ALL) until the archive area is available.
–
Stop automatic archiving, then restart, specifying a secondary location:
SVRMGR> ARCHIVE LOG STOP
SVRMGR> ARCHIVE LOG START ‘alt-location’
w
Rollback segment—The instance fails if the tablespace containing the
datafile contains active rollback segments. When this occurs, perform the
following steps:
a. Shut down the database if Oracle has not already done so.
b. Correct the problem. If the disk becomes unavailable for some time, you
can drop the missing segment, then add it again later.
c. Restart the database. Oracle recovers the database as usual, reconstructing
the missing rollback information from the online redo logs.
Enterprise eTIME Database Administrator’s Guide
2-55
Chapter 2
Managing Your Oracle Database
Permanent Loss of a Datafile
When the damaged or missing files are not part of the SYSTEM or rollback
tablespace, and the control file is intact, take the following steps to return the
database to normal:
1. Take the tablespace that contains the missing datafile or datafiles offline:
ALTER TABLESPACE ts1 OFFLINE FOR RECOVER;
The rest of the database remains accessible.
2. Restore the damaged file or files from the whole database backup using
appropriate operating system commands. Restore only the damaged files; do
not restore undamaged files, online redo log files, or the control file.
3. If you must restore the datafile to an alternate location (for example, after
permanent disk failure, or adding a new drive) perform the following steps:
a. Copy the file to its new location.
b. Enter the following SQL command to notify Oracle of the new location:
ALTER TABLESPACE ts1
RENAME DATAFILE ‘old-name’ TO ‘new-name’;
You can rename more than one file in the same command (separate file names
by commas) provided they are in the same tablespace.
RENAME DATAFILE changes the pointers to the datafile in the control file
but does not create, rename, or copy any operating system files. The file must
already exist in the location you specify in ‘new-name’. You must include
complete file specifications, and ‘old-name’ must exactly match the name of
the old datafile. To find the old name, look in the DBA_DATA_FILES view in
the data dictionary:
SELECT file_name, bytes FROM sys.dba_data_files
WHERE tablespace_name = ‘ts1’;
4. Apply the redo logs to recover. You might need to use archived redo logs as
well as the current online redo logs, as described in “Managing Redo Log
Files.”
5. For user damage, perform point-in-time recovery to just before the accidental
deletion took place. See the Oracle Backup and Recovery manual for
directions.
2-56
ADP, Inc.
Recovering and Restoring Damaged Databases
6. When recovery is complete, bring the datafile back online.
7. Back up the database immediately.
Permanent Loss of SYSTEM Datafiles or Rollback Segments
The SYSTEM tablespace contains the data dictionary, which must always be
available. If it is not, Oracle shuts the database down. Follow these steps to
recover:
1. Shut down the database if Oracle has not already done so.
2. Restore the damaged datafiles from the most recent backup. Do not restore
undamaged files, redo log files, or the control files.
3. Restart the instance and mount the database, but do not open it.
4. If you must restore the datafile to an alternate location (for example, after
permanent disk failure, or adding a new drive) perform the following steps:
a. Copy the file to its new location.
b. Enter the following SQL command to notify Oracle of the new location:
ALTER TABLESPACE ts1
RENAME DATAFILE ‘old-name’ TO ‘new-name’;
You can rename more than one file in the same command (separate file names
with commas) provided they are in the same tablespace.
RENAME DATAFILE changes the pointers to the datafile in the control file
but does not create, rename, or copy any operating system files. The file must
already exist in the location you specify in ‘new-name’. You must include
complete file specifications, and ‘old-name’ must exactly match the name of
the old datafile. To find the old name, look in the DBA_DATA_FILES view in
the data dictionary:
SELECT file_name, bytes FROM sys.dba_data_files
WHERE tablespace_name = ‘ts1’;
5. Apply archived and online redo logs as necessary.
Follow the same procedure to move a SYSTEM datafile to a different location; for
example, after a disk upgrade.
Enterprise eTIME Database Administrator’s Guide
2-57
Chapter 2
Managing Your Oracle Database
Permanent Loss of a Single Control File from a Multiplexed Set
Loss of any copy of the control file causes the instance to fail. Follow these steps
to recover:
1. Shut down the database if Oracle has not already done so.
2. Edit init*.ora to remove the reference to the missing file and to point to one of
your alternate control files.
3. Restart the database.
Loss of All Copies of the Control File
If you multiplex your control files, it is unlikely, but it is always possible that all
copies of the control file could be damaged or destroyed. Follow this procedure to
recover:
1. Restore the missing control file from the most recent backup.
2. Use the following command to recover the database:
RECOVER DATABASE dbname USING BACKUP CONTROLFILE...;
3. Apply all necessary archived and online redo logs.
You might not be able to recover completely.
Entire Database Is Gone
If the entire database is destroyed, you can re-create it as follows:
1. Restore from the last whole backup. The control file you restore should reflect
the database at the point in time to which you are recovering:
w
If you have a current control file and need to recover to the current point
in time, do not restore an older control file from a consistent whole
database backup. You need the current control file.
w
If you are recovering to a point in time, you need the control file that
corresponds to the database at that point.
2. Apply archived redo log files.
2-58
ADP, Inc.
Recovering and Restoring Damaged Databases
Improving Performance of Recovery
Restoring and recovering even a small database can take quite some time. To
make it faster to return your database to normal, you can consider one or more of
the following actions:
w
Investigate alternate backup strategies.
Archived backup logs combined with a whole database backup lets you
restore from nearly any failure, but the operation can be time-consuming. If
you need to minimize the amount of down time, you should look into options
such as backing up frequently used tablespaces more often, maintaining a
standby database, and so on. See the Oracle Backup and Recovery manual for
more information.
w
Limit “dirty” buffers.
Instance recovery performance is roughly proportional to the number of
modified buffers that had not been written to the database at the time of the
crash or other event that caused recovery to be needed. Such buffers are called
“dirty” buffers. Oracle automatically maintains a pointer to the oldest dirty
buffer in the redo log. Buffers before that point do not need to be processed
during instance recovery.
This process is called incremental checkpointing. This checkpointing takes
place independently of the other checkpoint operations. (See “Checkpoints.”)
Operations other than a full checkpoint cause data blocks to be written to disk,
so the incremental checkpoint are usually more recent than the full
checkpoint.
The DB_BLOCK_MAX_DIRTY_TARGET parameter limits the number of
dirty buffers that can be in memory at any one time. A smaller value for this
parameter forces buffers to be written more often. This requires more
processing while the database is running, but instance recovery takes less
time. If you have to be able to recover your database very quickly, or you use
very large buffer caches, experiment with changing this setting.
Enterprise eTIME Database Administrator’s Guide
2-59
Chapter 2
Managing Your Oracle Database
w
Recover only what needs to be recovered.
w
Consider offline recovery.
Recovery while the database is open runs in parallel with normal operations
and competes with normal transactions for resources. Depending on your
application, whether down time is acceptable, and how frequently you
perform whole database backups, it can be quicker to close the database for
recovery.
Restoring with Import
Sometimes it makes sense to import all or part of a database rather than restore it
from backups and reapply the logs. For example, a test or qualification database
might start from the same set of clean data before every test run.
Before you can import, you must have two things:
w
A database into which you can import
w
An export file created by the Oracle export utility
The database can be empty, or it can already include data. If it contains data, you
can import over the existing data or add the import to the existing data.
Oracle8 export files cannot be read by earlier versions of the Import utility. The
Import utility can read only binary format files written by the Export utility.
Note
Oracle8 files are forward compatible with Oracle 8i; that is, you can export files
from version 8 and import them to version 8i. However, the files are not backward
compatible; that is, you cannot export files from version 8i and import them to
version 8.
2-60
ADP, Inc.
Integrity Checking
Integrity Checking
Oracle provides a number of system parameters and SQL statements that allow
you to monitor the integrity of your database.
Enabling Redo Log Block Checking
Set the configuration parameter LOG_BLOCK_CHECKSUM=TRUE to enable
redo log block checking.
When redo log block checking is enabled, Oracle computes a checksum for each
redo log block as it is written to the current log, then writes this checksum to the
block header.
The ARCH process verifies the checksum before it writes the block to the archive.
If the block is corrupt, ARCH checks whether other members of the log group
contain a valid copy of the data block. If all members of the group are corrupt,
archiving cannot proceed.
If a checksum error occurs, you should immediately back up the database, because
the corrupt log file is not be available for recovery if the database fails. To make
the corrupt log file group available for logging again, run the following command
from the Server Manager utility:
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP n;
Updating ROWID Values
To reset ROWID values after an import that included REF columns and attributes,
use the VALIDATE REF UPDATE option, as follows:
ANALYZE TABLE [SCHEMA.]table VALIDATE REF UPDATE;
Enterprise eTIME Database Administrator’s Guide
2-61
Chapter 2
Managing Your Oracle Database
Verifying Access to Files
After a system crash, you can use CHECK DATAFILES to make sure all
necessary disks have been restored. Run the following command from the Server
Manager utility:
ALTER SYSTEM CHECK DATAFILES [GLOBAL];
CHECK DATAFILES verifies that the database instance can access all online
datafiles. If any datafile is not accessible, Oracle writes a message to the ALERT
file.
GLOBAL checks all instances if you are using the parallel server option.
2-62
ADP, Inc.
Performance and Tuning
Performance and Tuning
To keep your database running well, you need to monitor its performance and
correct any problems you find. The following sections explain some of the more
common performance-related tasks you might need to perform.
Checking the ALERT File
Whenever something goes wrong in your system, Oracle writes a message about it
in the ALERT file. This file is named alert.ora. You can specify a location for
alert.ora with the BACKGROUND_DUMP_DEST configuration parameter in
your init*.ora file. If you do not specify a location, Oracle uses the following
defaults:
w
$ORACLE_HOME\ADMIN\SID\BDUMP for Oracle on Windows NT
w
$ORACLE_HOME/rdbms/log for Oracle on UNIX systems
Correcting LGWR Delays
If LGWR (the log writer process) has to wait for a log group to become available,
either because a checkpoint has not completed or because ARCH (the archiver
process) is still writing the next log to the archive, you can investigate the
following solutions:
w
Add more log groups.
w
Move the archive to a faster disk.
w
Make the log files bigger.
w
If you are archiving directly to tape, consider archiving to disk and copying to
tape from the disk directory.
If Sessions Are Waiting for Other Sessions
The V$SESSION_WAIT data dictionary view lists events that cause sessions to
wait. See the Oracle Tuning manual for information about how to interpret this
information and correct any problems you identify.
Enterprise eTIME Database Administrator’s Guide
2-63
Chapter 2
Managing Your Oracle Database
Using DBReport
Follow these steps to run DBReport:
1. Log on to SQL*Plus.
2. Execute the script dbreport.sql by entering the following command:
start dbreport.sql
The script generates two reports and saves them in the file dbreport.rpt in the
current directory. The following tables describe the contents of the reports.
ADP Database Table Report
2-64
Column
Description
TABLE NAME
Name of the table
# ROWS
Number of rows in the table
BLOCKS
Number of blocks allocated for the table
TOTAL # BYTES
Total number of bytes that are allocated for the table
NEXT EXTENT
(BYTES)
Number of bytes that are allocated for the next disk extent
# OF EXTENTS
Number of extents that are allocated for the table
% MAX EXTENTS
Percentage of maximum extents that have already been
allocated for the table
CHAINED ROWS
Number of rows that have been relocated to alternate pages due
to row expansion
EMPTY BLOCKS
BELOW HWM
Proportion of completely empty blocks below the high-water
mark
TABLESPACE
Tablespace in which the table resides
ADP, Inc.
Performance and Tuning
ADP Database Index Report
Column
Description
INDEX NAME
Name of the index
TABLE NAME
Table to which the index applies
DISTINCT KEYS
Number of distinct entries in the index
BLEVEL
Number of levels within the index structure
TOTAL # BYTES
Total number of bytes that are allocated for the index
NEXT EXTENT
(BYTES)
Number of bytes that are allocated for the next disk extent
# OF EXTENTS
Number of extents that are allocated for the index
% MAX EXTENTS
Percentage of maximum extents that have already been
allocated for the index
Rebuilding Indexes
The index contains pointers to rows on the disk. The index lets you go directly to
the record of interest, making retrieval much quicker. Every time you add a row to
the database, Oracle updates the index. In time, the index can become fragmented.
When this happens, you need to drop and re-create the index.
You can also drop and re-create the index to improve the performance of bulk
loads. Be sure to back up your database immediately after a bulk load, because
such operations are not logged, thus invalidating the online redo logs. You should
also rebuild the index after you delete many records.
Enterprise eTIME applications provide SQL script files to make it easier to drop
and re-create dependent objects such as indexes when you perform large database
operations. These scripts generate a second SQL file tailored to your database and
the tables specific to Enterprise eTIME applications.
Enterprise eTIME Database Administrator’s Guide
2-65
Chapter 2
Managing Your Oracle Database
Dropping Dependent Objects
To drop all dependent objects from a set of tables, follow these steps:
1. Open the file dropddl.sql in a text editor.
2. Find the Usage section in the header of dropddl.sql. Follow the instructions in
this section to specify the necessary tables, and then save the file.
3. Log on to SQL*Plus.
4. Execute dropddl.sql to generate a file named drop.sql in the current directory.
Enter the following command:
start dropddl.sql
5. Execute drop.sql to drop all the dependent objects for the tables that you
specified in dropddl.sql. Enter the following command:
start drop.sql
Re-creating Dependent Objects
To re-create all dependent objects for a set of tables, follow these steps:
1. Open the file creatddl.sql.
2. Find the Usage section in the header of creatddl.sql. Follow the instructions in
this section to specify the necessary tables, and then save the file.
3. Log on to SQL*Plus.
4. Execute creatddl.sql to generate a file named create.sql in the current
directory. Enter the following command:
start creatddl.sql
5. Execute create.sql to re-create all the dependent objects for the tables that you
specified in creatddl.sql. Enter the following command:
start create.sql
2-66
ADP, Inc.
Performance and Tuning
Rebuilding Tables
Migrated and chained rows occur when an updated record becomes too large to fit
into the block where it was originally stored. When this happens, Oracle has to
move the record to a new location where it fits, and set the old location to point to
the new location. This means that in order to retrieve the record, Oracle might
have to access the disk twice: once to read the original location, and once to
retrieve the record from its new location.
A few chained records seldom affect performance, but many chained records can
slow performance. To identify chained rows in your system, you can use either of
the following commands:
w
ANALYZE tablel hr1 list chained rows;
w
SELECT * from chained_rows where table_name= ‘hr1’;
The setting for the DB_RW_MULTIBLOCK configuration parameter affects how
chained records are handled, and therefore can affect performance. Refer to the
Oracle Performance and Tuning Manual for details.
The Oracle Performance and Tuning manual includes a script that rebuilds tables
with too many chained rows. In addition, to running this script, you also should
adjust the PCTFREE value. The more update activity you have, the larger your
PCTFREE value should be. Refer to the Oracle Performance and Tuning Manual
for recommendations.
Coalescing Free Extents
Oracle allocates space within a segment using internal units called extents. When
a database operation requires space, Oracle scans the segment looking for an
available extent that is large enough to hold the data. If the data is deleted, the
extent is marked free.
Over time, several adjacent extents can be freed. Oracle does not recognize these
adjacent extents as a single free space unless they have been coalesced to combine
them into a single free extent, making a larger unit of free space available for
Oracle to use.
Enterprise eTIME Database Administrator’s Guide
2-67
Chapter 2
Managing Your Oracle Database
SMON periodically coalesces free extents for tablespaces that have a nonzero
value for the PCTINCREASE storage parameter. However, the Enterprise eTIME
database uses a PCTINCREASE of zero, so SMON never coalesces those
tablespaces. Temporary and rollback tablespaces also use a zero value. Therefore,
you must periodically coalesce free space in those tablespaces. Tablespaces can
remain online while the extents are being coalesced.
To manually coalesce the free space in a tablespace, run the ALTER
TABLESPACE command from the Server Manager utility:
ALTER TABLESPACE ts1 COALESCE;
To display the amount of coalesced free space in a tablespace, use the data
dictionary view DBA_FREE_SPACE_COALESCED, as shown in the following
SQL statement:
SELECT tablespace_name, percent_blocks_coalesced FROM
DBA_FREE_SPACE_COALESCED;
The lower the percentage, the more uncoalesced free space the table contains.
Ideally, PERCENT_BLOCKS_COALESCED should be 100%, meaning all
adjacent free extents are part of a single extent.
Updating Statistics
The optimizer determines the best and most efficient way to implement a query.
Oracle offers two optimizer choices: RULE for the old rule-based optimizer and
CHOOSE to use cost-based optimizing. Cost-based optimizing uses previously
gathered statistics to determine whether it is more efficient to scan the table or to
merge an existing index.
If the cost-based optimizing statistics are outdated, the optimizer can make poor
execution decisions. You should update statistics regularly, especially after large
operations, such as extensive additions or deletions. The more volatile an object
is, the more often it should be updated.
2-68
ADP, Inc.
Performance and Tuning
The initialization parameter OPTIMIZER _MODE lets you tell Oracle whether to
optimize for faster response or shorter execution time:
w
OPTIMIZER _MODE = FIRST_ROWS causes the optimizer to select plans
that shorten response time. This option is suitable if your database performs
primarily interactive queries.
w
OPTIMIZER _MODE = ALL_ROWS tells the optimizer to select plans that
shorten overall execution time. This is a good choice if you usually create
large reports. ALL_ROWS is the default.
You can update statistics using either the ADPStats utility or the ANALYZE
command. ANALYZE updates statistics for an individual table. It puts an
exclusive lock on the object being analyzed, so should be done during off-peak
hours.
> ANALYZE TABLE emp COMPUTE STATISTICS;
To run the Stats utility:
1. Log on to SQL*Plus.
2. Execute the script statsddl.sql to generate a file named stats.sql in the current
directory:
start statsddl.sql
3. Execute stats.sql to update all the statistics for objects in the Enterprise
eTIME database. Enter the following command:
start stats.sql
Enterprise eTIME Database Administrator’s Guide
2-69
Chapter 2
Managing Your Oracle Database
Recompiling Stored Procedures
After you recompute statistics, you should always recompile all stored procedures
to use the updated statistics. Otherwise they still use the outdated statistics. ADP
provides the Recomp utility to recompile the Enterprise eTIME stored procedures.
To run the Recomp utility:
1. Log on to SQL*Plus.
2. Execute the script recmpddl.sql to generate a file named recomp.sql in the
current directory. Enter the following command:
start recmpddl.sql
3. Execute recomp.sql to recompile all the stored procedures in the Enterprise
eTIME database. Enter the following command:
start recomp.sql
Hardware Solutions
To improve performance, you should also investigate hardware solutions: more
disks, more memory, RAID technology. Disk striping can increase performance,
especially on reads. Mirroring increases reliability. See the Oracle Backup and
Recover manual online for information about how to set up a standby database or
mirrored datafiles.
Disk striping combined with mirroring provides a fast but expensive solution. If
cost is not an issue, it is a good choice for online transaction processing databases
such as the Enterprise eTIME database.
2-70
ADP, Inc.
Chapter 3
Managing Your SQL Server 2000 Database
This chapter describes how to maintain, back up, and restore your Enterprise
eTIME databases on a Microsoft SQL Server 2000 RDBMS. It contains the
following sections:
w
Introduction
w
Managing SQL Server 2000
w
Managing Components of a SQL Server 2000 Database
w
Performing Backups
w
Restoring Damaged Databases
w
Integrity Checking with DBCC
w
Performance Analysis and Tuning
w
Rebuilding Indexes
w
Performing Automatic Backups
Chapter 3
Managing Your SQL Server 2000 Database
Introduction
This chapter explains only the most common techniques and features. It does not
explain all possible ways to do a task. It does not attempt to present complete SQL
statement syntax, cover all SQL Server Enterprise Manager options, or describe
every task that you might need to perform.
In most cases, you can perform the same task in any of several ways. For example,
you can access most SQL Server Enterprise Manager menu commands from the
menu, a button or shortcut, or by right-clicking the selected object to access a
shortcut menu. Most operations have equivalent SQL statements you can enter in
the Query Analyzer window. This chapter does not explain all possible options.
Unless otherwise stated, you should log in to SQL Server under the sa account.
Other accounts have fewer rights and might not be able to perform all the
necessary tasks.
For Additional Information
Many good courses and books exist. This list does not include them all.
w
w
w
3-2
About Windows NT and System Administration
–
Using Windows NT Server 4 by Roger Jennings et. al., Que Corporation
–
Microsoft SQL Server System Administration course
About SQL Server and Relational Databases
–
SQL Server Books Online
–
SQL Server 2000: The Complete Reference by Jeffrey Shapiro, Osbourne
Media Group
–
Inside Microsoft SQL Server 2000 by Kalen Delaney, Microsoft Press
–
Microsoft SQL Server Database and Application Performance course
About Database Administration
–
SQL Server Books Online
–
Microsoft SQL Server 2000 DBA Survival Guide by Mark Spenik and
Orryn Sledge, SAMS
ADP, Inc.
Managing SQL Server 2000
Managing SQL Server 2000
A “server” in SQL Server terms is any computer on which the SQL Server server
software is installed. The server can be a workstation or standalone PC.
SQL Server provides several different ways to reach database functions. The most
commonly used are the SQL Server Enterprise Manager graphical interface and
entering SQL statements with system procedures. This chapter explains both
methods. In most cases, it does not matter which interface you use.
Using SQL Server Enterprise Manager for Database Management
SQL Server Enterprise Manager is a graphical database management tool
included with SQL Server 2000. You can use SQL Server Enterprise Manager to
manage your entire database environment and perform nearly all of your database
maintenance tasks.
The following figure shows the SQL Server Enterprise Manager window:
Select Action > Refresh to update the displayed information for a selected object.
Enterprise eTIME Database Administrator’s Guide
3-3
Chapter 3
Managing Your SQL Server 2000 Database
Registering Servers
SQL Server Enterprise Manager requires you to register the servers you want to
manage. You register each server only once on each system from which you want
to perform administration functions:
1. Select Action > New SQL Server Registration. Click Next to use the
Register SQL Wizard.
2. Enter the name of one or more servers in the Server field, then click Add.
3. Click Next.
4. Select the option use SQL Server authentication, then click Next.
5. Enter the Server administrator login name and password. Click Next.
6. Click Next to add the server to the default SQL Server Group, or select
another group from the drop-down list and click Next.
7. Click Finish.
A message appears stating that the server was successfully registered.
8. Click Close.
The SQL Server Enterprise Manager displays the server’s name beside a server
status icon in the Server Manager window.
Defining and Using Server Groups
SQL Server Enterprise Manager places all servers in the SQL Server Group by
default. This is adequate for most applications. However, if you manage many
servers, it might be easier to group them by type, geography, or other shared
characteristics. To create other server groups:
1. Right-click on a registered server and select Edit SQL Server Registration
Properties.
2. Select a group in the Server Group drop-down list to create a new group, or
click the ellipsis button
to find the name of the group you want.
3. Click OK. The new group appears in the Server Enterprise Manager’s
window.
4. Double-click the group to display a list of servers.
3-4
ADP, Inc.
Managing SQL Server 2000
Using SQL Server
Before anyone can access databases under SQL Server, SQL Server itself must be
running. SQL Server normally runs as a Windows NT service called
MSSQLServer. By default, it does not start automatically when you start the
system. You can manage it through the SQL Server Enterprise Manager or
through the Windows Service Manager.
Starting SQL Server
To start the MSSQLServer service on the server, follow these steps. You need
Windows NT administrator rights on the server.
1. In the SQL Server Enterprise Manager’s object hierarchy, right-click the
server that you want to start.
2. Select Start.
If you are using any SQL Server scheduled jobs, you also need to start the SQL
Agent.
To start SQL Agent:
1. Double-click the server name.
2. Double-click Management.
3. Select SQL Server Agent.
4. Select Action > Start.
Configuring SQL Server to Start Automatically at Start Time
By default, SQL Server must be started manually. This means that every time you
want SQL Server to be available on a system, you have to remember to start it. To
have it start automatically whenever the system starts, change the MSSQLServer
startup parameters from the Server Enterprise Manager:
1. In the SQL Server Enterprise Manager, select the server on which you want
MSSQLServer to start automatically.
2. Select Action > Properties. Make sure that the Autostart SQL server option
is selected.
Enterprise eTIME Database Administrator’s Guide
3-5
Chapter 3
Managing Your SQL Server 2000 Database
3. If you are using any SQL Server scheduled jobs, make sure the Autostart SQL
Server Agent option is selected.
4. Click OK.
You can also configure the services from the Windows NT Services panel.
Stopping SQL Server
You can stop SQL Server locally, or you can stop it from a client or from another
server. You can use SQL Server Enterprise Manager, SQL Service Manager,
Query Analyzer, or the net stop command from the server’s operating system
prompt.
The recommended sequence for a shutdown that is not an emergency is as
follows:
1. Pause the MSSQLServer service to prevent new users from gaining access to
the system.
Current users can finish their work and exit. To do so, select the server that
you want to pause, then select Action > Pause.
2. Broadcast one or more messages warning users that SQL Server is about to
shut down. Use the net send/users command at the server’s operating system
prompt. For example:
net send /users “SQL Server will be shut down for
maintenance at 14:30. Please finish your work and
disconnect from all SQL Server databases.”
3. After an appropriate interval, select the server that you want to stop, then
select Action > Stop.
The system waits for currently executing SQL statements and stored
procedures to finish before shutting down.
As part of the shutdown procedure, the server writes a checkpoint record to every
database, causing each database to have a checkpoint when SQL Server restarts.
This record counts as an alteration for purposes of loading backup files.
3-6
ADP, Inc.
Managing SQL Server 2000
This means that if SQL Server or the system goes down while you are applying
transaction logs, you must start over, because the checkpoint record invalidates
your transaction log sequence. SHUTDOWN WITH NOWAIT, when executing in
Query Analyzer, does not write the checkpoint record.
If you need to bring the system to an immediate halt, use SHUTDOWN WITH
NOWAIT to stop the system without waiting for current statements to finish, or
stop the service from the Windows NT Services panel.
Using SQL Statements for Database Management
You can execute most database management operations using SQL statements and
system stored procedures.
To enter SQL statements, open the Query Analyzer utility (Start > Programs >
Microsoft SQL Server > Query Analyzer). This tool lets you enter SQL queries
to get information from the database or perform maintenance functions on the
database.
Query Analyzer does not require you to register the servers you will monitor. The
Query Analyzer login window opens automatically when you open Query
Analyzer. To log in, provide the login ID and password for the server you want to
manage.
Unlike SQL Server Enterprise Manager, which allows only one registration per
machine, Query Analyzer allows multiple connections to the same server, under
the same or different login IDs. To connect to additional servers, select File >
Connect from the menu bar and fill out the login window for the new connection.
Within Query Analyzer, you can execute multiple queries simultaneously by
including the word “go” between SQL statements. This tells SQL Server to expect
another command.
The syntax shown in this chapter represents typical SQL Server usage. It is not a
complete syntax diagram and does not show every option. If you need details
about the syntax, consult the SQL Books Online.
Enterprise eTIME Database Administrator’s Guide
3-7
Chapter 3
Managing Your SQL Server 2000 Database
Managing Components of a SQL Server 2000 Database
A database under SQL Server resides on one or more operating system files. The
database consists of a data portion and a log portion, which must be in separate
data files. Each data file is a member of a filegroup. Filegroups let you specify
where database objects are physically stored. When you create a database, you
specify the files for the database data and the transaction log.
This section describes:
w
Managing Databases
w
Managing Transaction Logs
w
Managing Filegroups
w
Managing Backups
Managing Databases
Managing databases involves:
w
Defining and setting up the database
w
Managing Transaction logs
The following sections describe these procedures.
Defining Databases
When you create a database, you specify the files for the database data and for the
transaction log. You can add files at any time after you create the database. See the
SQL Server Books Online for information about other creation options you can
use.
See the Enterprise eTIME Database Administrator’s Guide for instructions about
how to create the database if you have fewer disks than recommended.
3-8
ADP, Inc.
Managing Components of a SQL Server 2000 Database
To define a database, follow these steps:
1. Select Start > Programs > Microsoft SQL Server > Enterprise Manager.
2. Double-click the server name.
3. Select the Databases folder.
4. Select Action > New Database.
The DB properties dialog box appears.
5. Enter the Database name.
6. Accept the default database file location or use Browse to change the location.
7. Enter a database file name in the first blank file name column below the
default data file.
For example, for the database named tkcsdb, the file name might be
tkcsdb_data_tkcs1.
8. Accept the default file location in the Location column or use Browse to
change the location.
9. Enter a filegroup name in the Filegroup column. You must use tkcs1 through
tkcs8.
10. Repeat steps 7 through 9 for as many database files as necessary.
11. In the File properties section, accept the defaults. Optionally, you can restrict
the Maximum File Size if there is a shortage of disk space on the server.
12. Click OK.
13. Enter transaction log files information:
a. Select the Transaction Log tab.
b. Use Browse to change the location of the log file listed.
ADP recommends that you keep the log file on a different disk from the
data files.
c. Accept the defaults for the File properties fields and click OK.
14. Select Action > Refresh to view the new database.
Enterprise eTIME Database Administrator’s Guide
3-9
Chapter 3
Managing Your SQL Server 2000 Database
Setting Database Options
Database options set characteristics of database behavior, such as whether more
than one user can access the database or whether nonlogged operations are
allowed. The most commonly used options are DBO Use Only, meaning that only
the database owner or system administrator can use the database, and Single User,
meaning only one user at a time can use the database. These options exclude other
users from the database while you perform critical operations.
To set database options:
1. Select the database in the SQL Server Enterprise Manager and then select
Action > Properties.
2. Select the Options tab.
3. Select the options you want to enforce. Clear the options you want to remove.
4. Click OK to apply the changes.
Getting Information About Databases
The sp_helpdb system stored procedure displays database information. The output
looks similar to the following for a tkcsdb database that uses the recommended
options. Your installation information will vary.
Device and segment information appears only if you are connected to the database
when you run sp_helpdb. When you run this procedure, include the name of the
database as a parameter. For example:
sp_helpdb wfcdb
3-10
ADP, Inc.
Managing Components of a SQL Server 2000 Database
Managing Transaction Logs
To restore a database to its original structure and contents, SQL Server needs to
know every change that was made to that database. It accomplishes this by
recording information about every change in the transaction log file. The
transaction log file should reside on a separate disk from the data files so that disk
I/0 is spread out over separate disks.
Providing Adequate Disk Space for the Transaction Log
Many factors influence whether you have enough disk space for your transaction
log: the size of the database, the frequency of changes to the database, and the
frequency of full and incremental backups are among the most important.
Generally, the more often the database changes and the less often you perform
backups, the larger the transaction log needs to be. Make sure you take these
factors into consideration when you allocate space for your transaction log.
Enterprise eTIME Database Administrator’s Guide
3-11
Chapter 3
Managing Your SQL Server 2000 Database
If there is not enough room for your transaction log, you receive error 1105,
“Can't allocate space for object 'Syslogs' in database 'smalldb' because the
'logsegment' segment is full.” By default, log space is dynamically allocated.
Therefore, the only time you normally receive this error is if you have run out of
disk space. See “Backing Up a Full Transaction Log” for what to do in this
situation. Then either perform backups more often, increase the size of the
transaction log, or both.
Understanding How Transaction Logs Work
While a transaction is in progress, it is written to the database cache and to the
transaction log, but it is marked as uncommitted. If the user cancels the operation,
or the operation fails for other reasons, the information is removed from the cache
and from the transaction log. This is called rolling back a transaction.
When the transaction completes successfully, the transaction log receives a
commit record, which is immediately written to disk. The records changed by the
transaction are then written to the database. This ensures that the changes are
recovered and the database remains in a consistent state even if the disk fails while
the database records are being written.
The database records stay in the cache until another transaction needs the space or
a checkpoint causes all modified pages to be written to the disk. The modified
page in memory is called a “dirty” page.
Managing Filegroups
The Enterprise eTIME database uses filegroups. A SQL Server database has one
filegroup by default–PRIMARY–to store the system tables as well as other
database objects unless you create additional filegroups.
The Enterprise eTIME Database Installation Guide explains how to create the
filegroups SQL Server needs and how to distribute them across the disks. Once
the filegroups are created, you do not need to do anything with them unless you
need to re-create the database. Your Enterprise eTIME application takes care of
placing indexes, tables, and so on, in the appropriate filegroup.
3-12
ADP, Inc.
Managing Components of a SQL Server 2000 Database
Use the sp_helpfile and sp_helpfilegroup stored procedure to display information
about database filegroups and files. You must be connected to the database from
which you want information. The output from sp_helpfilegroup is similar to the
following example:
groupname
group id
filecount
-----------------------------------------Primary
1
1
tkcs1
2
1
tkcs2
3
1
tkcs3
4
1
tkcs4
5
1
tkcs5
6
1
tkcs6
7
1
tkcs7
8
1
tkcs8
9
1
The following illustration shows a sample filegroup configuration of database
devices for the Enterprise eTIME database. The Enterprise eTIME Database
Installation Guide explains how to distribute the logical devices when you do not
have the recommended number of disks to devote to the Enterprise eTIME
database.
Enterprise eTIME Database Administrator’s Guide
3-13
Chapter 3
Managing Your SQL Server 2000 Database
File creation can fail if the SQL Server process does not have the operating system
right to create the physical file, or if there is not enough space on the disk to create
a file of the size you specify.
3-14
ADP, Inc.
Managing Components of a SQL Server 2000 Database
Getting Information About Data and Log Files
To get information about files in your system, use the system stored procedure
sp_helpdb. The output looks similar to the following command:
sp_helpdb tkcsdata1
Your display varies depending on how you defined your files and filegroups.
Managing Backups
SQL Server 2000 backup device objects (backup devices) are files that store
databases. They connect the database as the user sees it to the actual physical
devices that make up the system. Backup files receive full and incremental
backups. These devices are commonly located on local disks, but can also be on
network disk drives, local tape drives, or named pipes. The SQL command to
back up a database or transaction log is BACKUP.
In addition to the database devices for the Enterprise eTIME database, you need to
define one or more backup devices for SQL Server itself.
You can define your backup files ahead of time as permanent devices, or specify a
temporary device at the time you execute the backup. The file is not created until a
backup is performed to that device.
Enterprise eTIME Database Administrator’s Guide
3-15
Chapter 3
Managing Your SQL Server 2000 Database
Backup Tips
Keep the following in mind as you develop and implement your backup strategy:
w
If you choose the SQL Server Full Recovery or Bulk-Logged Recovery
models, the Transaction Log can grow very quickly and should be scheduled
for backup at multiple times throughout the day. Performing multiple backups
ensures that the log is truncated frequently and provides for improved data
recoverability.
w
If you choose the Simple Recovery Model (formerly known as Truncate Log
on Checkpoint), schedule full database backups should be scheduled for at
least once per day. With this method, data recoverability is limited to the last
full database backup.
w
ADP strongly recommends that you back up your database often to protect
your data against hardware or software failures, and other acts of nature.
Database backups should be stored off-site when possible or appropriate.
For instructions about running backups on your database, see the sections
“Performing Full Backups” and “Performing Incremental Backups” later in this
chapter.
Defining Backup Devices
You can define new backup devices at any time, and back up any database to
them. However, it is good practice to have at least one backup device for each
database, and to give that device a name that clearly describes the database with
which it is associated. For example, you might name the backup device for wtkdb
WTKDB_BACKUPS.
3-16
ADP, Inc.
Managing Components of a SQL Server 2000 Database
To define a backup device, follow these steps.
1. Double-click the server name, then double-click Management.
2. Select Backup, then select Action > New Backup Device.
3. Enter the name of the device in the Name field.
4. Enter the full path name for the backup file you want to use, or click the
ellipsis button
to browse the local system for the drive and directory you
want.
5. Click OK.
Using SQL Statements
Use the sp_addumpdevice system procedure to add a disk backup device:
sp_addumpdevice ’disk’, ’logical_name’,’physical_name’
Defining Temporary Backup Devices
A temporary backup device is created at the time of the backup. It is not defined in
the master database; you specify it as part of the BACKUP DATABASE or
BACKUP TRANSACTION statements.
You create a temporary backup device by specifying the type of medium on which
the backup file is stored and the complete path including file name. You can also
use a variable to identify the backup device. The clause defining a temporary
backup device looks something like this:
{DISK|TAPE|PIPE}= ’temp_dump_device’
The temp_dump_device specification must follow operating system syntax rules
for a disk or tape drive. For a network backup device, the name must conform to
the universal naming convention (UNC). PIPE requires the name of the named
pipe used in the client application.
Enterprise eTIME Database Administrator’s Guide
3-17
Chapter 3
Managing Your SQL Server 2000 Database
Performing Backups
The following sections explain how to do full and incremental backups in SQL
Server Enterprise Manager.
In addition to regularly scheduled backups, you should back up a database
immediately after you make extensive changes or perform nonlogged operations.
Back up the master database any time you perform an operation that alters the
structure of any database. Otherwise, you lose information about those changes if
the master database fails. These operations include:
w
Adding, changing, or removing databases or files
w
Adding or removing system login IDs
w
Changing system configuration parameters
Be sure to include regular backups of the master and msdb databases as part of
your overall backup strategy. The master database contains information about the
databases on your system and the msdb database stores information about
scheduled jobs.
Performing Full Backups
You do not need to close the database before you start a backup, but you do need
to make sure that the backup device is defined, or that the backup command
includes the specification for a temporary backup device (see “Defining
Temporary Backup Devices”).
You can optionally perform the following:
3-18
w
Run the DBCC command Checkdb to make sure the database does not
contain errors (see “Integrity Checking with DBCC”).
w
Use BACKUP TRANSACTION dbname TRUNCATE_ONLY immediately
before you begin a full backup. This makes the full backup go faster.
ADP, Inc.
Performing Backups
Using the SQL Server Enterprise Manager
To perform a full backup using SQL Server Enterprise Manager, do the following:
1. Double-click the server name.
2. Double-click the Databases folder.
3. Right-click the database.
4. Select All Tasks > Backup Database.
The General tab appears.
5. Accept the default name or enter a backup name in the name field.
6. You can optionally add a description that includes the reason for the backup.
7. Select Database-complete in the Backup field.
8. Select the destination media.
9. If you want to append to an existing file, accept the default in the Overwrite
field. Otherwise, select Overwrite existing media.
10. Optionally, schedule the complete backup to occur at a specific time by
selecting the schedule check box and defining a schedule.
11. You can also set other backup parameters, such as verification and backup
expiration date, by making selections in the Options tab.
12. Select OK to start the backup.
Using SQL Statements
The basic SQL statement to back up a database is:
BACKUP DATABASE dbname
TO backup_device [, backup_device2
[..., backup_device32]]
[WITH {INIT | NOINIT}]
Enterprise eTIME Database Administrator’s Guide
3-19
Chapter 3
Managing Your SQL Server 2000 Database
The backup_device is the name of the backup device as specified when you
created it. You can specify up to 32 backup devices; SQL Server automatically
distributes the backup across the devices you specify. This is called a striped
backup. When you restore from a striped backup, all the devices that were part of
the original backup must be available or the restore fails.
INIT tells SQL Server to initialize the backup device, removing all previous data,
before it writes the backup information. NOINIT is the default; it causes the new
backup to be appended to the old backup, leaving the old backup still available.
The advantage of appending backups is that you save other backup versions in
case there is a problem with more recent ones. The disadvantage is that the
appended backups quickly create very large backup files. Also, if you lose the
backup file, you lose several backups.
BACKUP DATABASE has other options, most of which are useful with tape
backup devices. See the SQL Books Online for syntax and rules of these options.
Performing Incremental Backups
An incremental backup makes a copy of a portion of the transaction log. It
includes the transactions from the point of the previous full or incremental backup
to the transactions that were committed at the time you begin the incremental
backup. Transactions that were active when the incremental backup begins are not
included even if they are committed before the backup ends.
You must have performed a full database backup as described in “Performing Full
Backups” on page 3-18 before you can perform an incremental backup, usually
called a transaction log dump in SQL Server. In addition, check the following:
3-20
w
Make sure the database option Truncate Log on Checkpoint is not set. This
option causes the transaction log to be emptied every time SQL Server
performs a checkpoint operation, usually every few minutes.
w
The incremental backup fails if a nonlogged operation has been performed
since the last backup. Perform a full backup instead.
ADP, Inc.
Performing Backups
Using SQL Server Enterprise Manager
To perform an incremental backup using SQL Server Enterprise Manager, do the
following:
1. Double-click the server name.
2. Double-click the Databases folder.
3. Right-click the database.
4. Select All Tasks > Backup Database. The General tab appears.
5. Accept the default name or enter a backup name in the name field.
6. You can optionally add a description that includes the reason for the backup.
7. Select Transaction log in the Backup field.
8. Select the destination media.
9. If you want to append to the existing file, select Append to Media in the
Overwrite field. Otherwise, select Overwrite existing media.
10. Optionally schedule the incremental backup to occur at a specific time by
selecting the schedule check box and defining a schedule.
11. You can also set other backup parameters, such as verification and backup
expiration date, by making selections in the Options tab.
12. Select OK to start the backup.
Using SQL Statements
The SQL statement to back up the transaction log is:
BACKUP LOG dbname
TO backup_device [, backup_device2
[..., backup_device32]]]
[WITH {TRUNCATE_ONLY | NO_LOG | NO_TRUNCATE}
[{INIT | NOINIT}]
INIT and NOINIT have the same meaning for transaction log backups as for full
backups. If you use INIT with a transaction log backup, make sure previous
backups on the same device have been copied to another location. Otherwise, you
delete interim incremental backups and make the current backup unusable.
Enterprise eTIME Database Administrator’s Guide
3-21
Chapter 3
Managing Your SQL Server 2000 Database
TRUNCATE_ONLY removes the inactive part of the transaction log without
copying any part of the log to the backup file. Therefore, you do not need to
specify a backup device with this option. If you do not use the transaction logs for
incremental backup, you should periodically use TRUNCATE_ONLY to keep the
database or transaction log from growing too large. The master database should be
backed up using TRUNCATE_ONLY.
NO_LOG removes the inactive part of the transaction log without logging the
truncation operation itself. This option allows you to continue when the
transaction log has become so full that it does not have room to write the log
record from a normal BACKUP LOG command. If you are forced to use the
NO_LOG option, immediately start a full backup.
NO_TRUNCATE uses the master database’s pointer to the transaction log to
recover the undamaged transaction log of a damaged user database, provided the
transaction log resides on a separate device from the user database and the master
database is still intact.
What Happens During Backup
When you issue a BACKUP DATABASE command either directly or through
SQL Server Enterprise Manager, SQL Server performs the following steps:
1. Writes all completed transactions to disk
2. Performs any necessary initialization of the backup device, such as reading
the header, appending or overwriting existing backups, and so on
3. Copies the database
Backing Up a Full Transaction Log
If the transaction log becomes so full that you cannot back it up normally, use the
BACKUP LOG dbname WITH NO_LOG command to free space, then
immediately perform a full backup. SQL Server backs up the transaction log and
truncates the inactive part without writing a log record. You should then expand
the transaction log to another disk, if possible.
3-22
ADP, Inc.
Performing Backups
Hot and Warm Backups
A warm backup, also called a standby system, is a duplicate system that is kept
in sync with the main system so it can replace the main system with very little
down time. The most common way to achieve this is to set up a duplicate system
with identical files, databases, logins, and user accounts, as well as filegroups and
other database characteristics.
Each time you perform a backup on the primary server, immediately load the
backup file onto the backup server. If the primary server develops a problem, you
lose only the time it takes to get the primary offline and the backup online. Note
that this could be several hours if you have a very large, active database and the
primary system goes down just as the backup is starting to load on the secondary
server.
The backup server should be set with the database options Read Only and No
Checkpoint On Recovery to prevent update activity from taking place on the
backup server. No checkpoint means SQL Server does not write the checkpoint
record when it goes down. Thus, the logs remain valid. Read Only ensures that no
accidental changes invalidate the transaction logs being loaded. Reset this option
just before you load the transaction log.
A hot backup includes any of several methods of making sure the database never
goes down. It includes making backups while the database is in use and making
sure one system is ready to take over immediately if the primary server goes
down.
Most SQL Server hot backup solutions rely on hardware. You place the database
on a disk device that is shared between two systems that communicate with each
other constantly about their state. If the primary system goes down, the secondary
system is immediately aware of it and takes over the function of primary server.
Enterprise eTIME Database Administrator’s Guide
3-23
Chapter 3
Managing Your SQL Server 2000 Database
Restoring Damaged Databases
This section describes the steps you need to follow to return a damaged database
to normal.
Before You Start
w
You cannot load into a database that is being used. If you are attached to the
database, you are using it. Make sure no other users are attached to the
database, and then connect to a different database before you start the restore.
w
If you are loading the backup file into a database on a different server, both
systems must use the same code page and sort order.
w
Remember that any data already existing in the database are overwritten.
Automatic Recovery
SQL Server automatically recovers each database whenever SQL Server starts.
The process is the same whether the shutdown was normal or unexpected. SQL
Server checks each database in the system, starting with the system database.
w
It rolls back uncommitted transactions.
w
It writes to the database any committed transactions that were still in the
cache (the “dirty” pages).
w
It removes the inactive portion of the transaction log. (The inactive portion is
the part that includes committed transactions up to the oldest open active
transaction. An active transaction is neither committed nor rolled back.)
Sometimes an old transaction cannot close; this can make it impossible to truncate
the transaction log. See the SQL Books Online for directions about how to locate
and clear an open transaction.
3-24
ADP, Inc.
Restoring Damaged Databases
Restoring a Complete Database Backup
If your master and msdb databases are intact, you can use the Restore database
function to restore the database.
Before restoring, make sure you close all database connections.
To restore a complete database backup using SQL Server Enterprise Manager,
follow these steps:
1. Double-click the server name.
2. Double-click the Databases folder.
3. Right-click the database. Make sure you select the correct database before
running the restore.
4. Select All Tasks > Restore Database.
The General tab appears.
5. Accept the default or select a backup from the drop-down list in the Show
backups of database field.
6. Check the dates, times, and names, and select one full backup to restore in the
First backup to restore field.
7. Deselect any existing incremental backups.
8. Click OK.
9. When the Restore database procedure is complete, a Restore Successful
message appears. Click OK to complete the restoration.
Enterprise eTIME Database Administrator’s Guide
3-25
Chapter 3
Managing Your SQL Server 2000 Database
Point-in-Time Recovery
You can specify that only part of a transaction log be restored. This is especially
useful if you know the point at which data corruption, such as an accidental
deletion, occurred.
As with any database restore, make sure you close all database connections.
To perform a partial restoration using SQL Server Enterprise Manager:
1. Double-click the server name.
2. Double-click the Databases folder.
3. Right-click the database. Make sure you have selected the correct database
before running the restore.
4. Select All Tasks > Restore Database.
The General tab appears.
5. Accept the default or select a backup from the drop-down list in the Show
backups of database field.
6. Check the dates, times, and names and select one full backup to restore in the
First backup to restore field.
7. Determine which incremental backup sets you want to restore. Deselect the
backup sets you do not want to include.
8. Click OK.
9. When the Restore database procedure is complete, a Restore Successful
message appears. Click OK to complete the restoration.
3-26
ADP, Inc.
Restoring Damaged Databases
Restoring When the Database Must Be Re-created
If the database files have been lost, perhaps due to disk failure or severe
corruption, you can restore by deleting the database, re-creating it, and loading it
using SQL Server Enterprise Manager.
If your database has become corrupted, only recover to the last “good” backup
(incremental or full) if you know when the corruption occurred.
To re-create the database and restore it, use SQL Server Enterprise Manager and
follow these steps:
1. Select the Databases folder.
2. Select the database. Make sure you have selected the correct database.
3. Select Action > Delete.
4. Click Yes when prompted to delete the database.
5. Create the database as described in “Defining Databases.”
6. Restore the database by performing a complete database backup restoration as
described in “Point-in-Time Recovery.”
Restoring a Corrupt Database
If database corruption causes your database to fail, you can use NO_TRUNCATE
to recover the last changes in the transaction log. This option works only when the
master database is not corrupted. It causes SQL Server to write transaction log
entries from the time of the last incremental backup to the point of corruption.
This backup file becomes the last incremental backup to bring the database up to
the minute. You can then recover a corrupt database through the restore procedure
described in “Restoring When the Database Must Be Re-created.”
Recovering the Master Database
If you created a backup, you can recover the master database as you would any
other database as described in “Restoring When the Database Must Be Recreated.” However, the server must be in single-user mode.
Enterprise eTIME Database Administrator’s Guide
3-27
Chapter 3
Managing Your SQL Server 2000 Database
To enter single user mode:
1. Stop SQL Server.
2. On the database server desktop, select Start > Programs > Command
Prompt.
3. At the DOS prompt, enter the following command:
sqlservr.exe -m
4. Follow the procedure describes in “Restoring a Complete Database Backup.”
3-28
ADP, Inc.
Integrity Checking with DBCC
Integrity Checking with DBCC
Databases sometimes become corrupted, and corruption can be so severe it
prevents an otherwise successful backup from loading properly. Therefore, you
need to periodically check your database’s structural integrity.
Microsoft SQL Server supplies DBCC (for Database Consistency Checker) to
help you detect and fix structural integrity problems. You issue DBCC commands
from Query Analyzer or a DOS .bat file. You can use the Database Maintenance
Plan Wizard in SQL Server Enterprise Manager to create a schedule to run DBCC
commands.
Other DBCC commands return performance information. Those commands are
explained in “Performance Analysis and Tuning.”
You should run DBCC commands on both your Enterprise eTIME and master
databases.
Using Checkdb
Checkdb checks each table in a database for pointer and data page errors. Its
syntax is:
DBCC CHECKDB (dbname [, NOINDEX]) [WITH NO_INFOMSGS]
The database name is optional if you are attached to the database. NOINDEX tells
DBCC to skip nonclustered indexes in user tables, thus speeding execution and
reducing contention. WITH NO _INFOMSGS suppresses informational
messages, making it easier to see errors in the output.
Checkdb can be used during normal operating hours; however, it can cause
significant locking contention and performance degradation.
Enterprise eTIME Database Administrator’s Guide
3-29
Chapter 3
Managing Your SQL Server 2000 Database
Performance Analysis and Tuning
The Enterprise eTIME database takes care of many common database
administration tasks, such as defining indexes and determining where to place
them. But you still need to monitor space and memory requirements, and
periodically check to see whether your tables have grown to the point where the
indexes need to be rebuilt.
Understanding the DBReport Utility
The DBReport utility generates a report about the current condition of the
Enterprise eTIME database.
You run DBReport from Query Analyzer, as follows:
1. In Query Analyzer, connect to the Enterprise eTIME database.
2. Open the file dbreport.sql by clicking the Open button
and selecting the
file in the dialog box. By default, this file is installed in
\ADP\Scripts\Database\MSS\DBAutilities, but you can copy it to any
convenient directory.
Query Analyzer inserts the code into your current window.
3. Click the Execute button
to execute the code.
The report is generated and appears in the Results window.
4. Examine the report in the Results window by scrolling through the output.
The actual report can be preceded by several pages of preliminary output. To
find the beginning of the report, search for the expression “ADP Database
Report.”
The columns in the report provide the following information:
3-30
w
The Table column lists the names of every table in the database.
w
Rows tells how many rows are currently in the table.
w
Pages tells how many pages are allocated for the table.
w
Space tells how much space, in megabytes, is allocated for the table.
ADP, Inc.
Performance Analysis and Tuning
w
The Last Update of Statistics column tells when the UPDATE STATISTICS
command was last run against the table. Because this report was generated
from a newly created database, it shows a value of null for all columns,
meaning statistics have never been generated. The value is also null for tables
with no indexes, since they have no statistics.
The following example shows part of a report generated by dbreport.sql.
Note
The DBCC Show Config output follows the list of tables.
Enterprise eTIME Database Administrator’s Guide
3-31
Chapter 3
Managing Your SQL Server 2000 Database
Rebuilding Indexes
Overview
As your database grows and changes, you need to rebuild your indexes.
As pages of data fill up, inserts and updates take longer due to page splits.
Rebuilding clustered indexes returns the database pages to their original fill
factors. Rebuild your indexes using the DBCC Dbreindex command in Query
Analyzer.
Rebuilding indexes does not require you to shut down the database, but since the
entire table is locked for the duration of the operation, ADP strongly recommends
shutting down. Set the DBO Only and Single User Only database options. Since
rebuilding an index requires unloading the table, sorting it, and reloading, it can
take a significant amount of time and space in tempdb.
The syntax for the DBCC dbreindex command is:
DBCC DBREINDEX (table_name [,index_name [,fillfactor]])
[WITH NOINFOMSGS]
table_name specifies the table whose indexes you want to rebuild.
index_name limits the rebuilding to the named index; if you omit index_name,
all of that table’s indexes are rebuilt. If you want all indexes rebuilt, and also want
to specify a fill factor, give the index_name two single quotes (“) to
indicate a null string.
fillfactor identifies the fill factor at which the indexes are rebuilt. Specify 0
(zero) to rebuild at the table’s original fill factor.
WITH NOINFOMSGS suppresses display of informational messages so you can
see errors more clearly.
3-32
ADP, Inc.
Rebuilding Indexes
Dropping and Re-creating Indexes and Other Dependent Objects
The Enterprise eTIME database includes SQL script files to generate the DDL
statements to drop and re-create indexes, constraints, and other dependent objects.
To drop all objects that depend on a set of tables:
1. In Query Analyzer, open the file dropddl.sql.
2. Find the Usage section in the header of dropddl.sql. Follow the instructions in
the Usage section to specify the necessary tables.
3. Click the Execute button
to execute dropddl.sql.
The required DDL is generated and displayed.
4. Save the output to a file named drop.sql.
5. Open the file drop.sql.
6. Click the Execute button to execute drop.sql.
Executing this file drops all the dependent objects for the tables you specified
in dropddl.sql.
To re-create all objects that depend on a set of tables:
1. In Query Analyzer, open the file creatddl.sql.
2. Find the Usage section in the header of creatddl.sql. Follow the instructions in
the Usage section to specify the necessary tables.
3. Click the Execute button
to execute creatddl.sql.
The required DDL is generated and displayed.
4. Save the output to a file named create.sql.
5. Open the file create.sql.
6. Click the Execute button to execute create.sql.
Executing this file re-creates all the dependent objects for the tables you
specified in creatddl.sql.
Enterprise eTIME Database Administrator’s Guide
3-33
Chapter 3
Managing Your SQL Server 2000 Database
Performing Automatic Backups
SQL Server provides several ways to automate your backup tasks:
w
Use the SQL Server Enterprise Manager’s Maintenance Plan Wizard
w
Use batch files scheduled through the Windows scheduling facility
Monitor whichever method you use for accuracy and reliability. Always verify
that the backup ran, and if it failed for some reason, fix it now rather than waiting
for the next scheduled backup.
Scheduling Maintenance Through SQL Server Enterprise Manager
Use SQL Server Enterprise Manager’s Database Maintenance Plan Wizard to
schedule maintenance tasks. The wizard takes information about your database
and system and generates a maintenance schedule based on that input.
To start the Database Maintenance Plan Wizard, perform the following steps:
1. Click the server and select Tools > Database Maintenance Planner to
display the Database Maintenance Plan Wizard.
2. Click Next. The Select Databases screen appears:
3-34
ADP, Inc.
Performing Automatic Backups
3. Select the databases for which you want to set up a maintenance plan.
4. Click the Next button to go to the next window.
5. The wizard asks you about your database characteristics and scheduling
needs. Enter the requested data in each screen, then click the Next button to
go to the next screen.
6. When you complete the final screen and click Next, the wizard creates the
tasks and schedules them.
7. You can monitor and change the new tasks from SQL Server Enterprise
Manager as with any other task, as follows:
a. Double-click the server name, then double-click Management.
b. Select SQL Server Agent, then select Jobs.
Running Maintenance Utilities from DOS Batch Files
You can run any SQL command (such as DBCC or DUMP) or DBA Utility task
through OSQL from DOS .bat files. These tasks can be in addition to or to replace
SQL Server Enterprise Manager scheduled tasks. You can run these .bat files
individually, or schedule them to run in the Windows scheduling facility.
For example, your DOS .bat file might be called dailysch.bat. It would contain the
command to start isql and read an input file:
osql -Utkcsowner -d dbname -P<tkcsowner password> -s
servername -n -ic:\dump.in -oc:\dump.out
Note
Substitute the actual tkcsowner password at your site for <tkcsowner password>.
The file dump.in contains the following text:
backup database tkcsdb to tkcsdb_dump
Enterprise eTIME Database Administrator’s Guide
3-35
Chapter 3
Managing Your SQL Server 2000 Database
After execution, the file dump.out contains text similar to the following:
Database ‘tkcsdb’ (17567 pages) dumped to file <2> on
device ‘tkcsdb_dump’
See the SQL Server Books Online for more information.
3-36
ADP, Inc.
Chapter 4
Installing and Configuring Automated SQL
Server Database Maintenance Utilities Scripts
This chapter describes the steps for installing and configuring Automated
Database Maintenance Utilities that you can use on a SQL Server database. It
contains the following sections:
w
About the Automated Database Maintenance Utilities
w
System Requirements
w
Installation Checklists
w
Performing Automated Database Maintenance Utilities Tasks
Note
The Automated Database Maintenance Utilities are only supported on Enterprise
eTIME on a SQL Server database.
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
About the Automated Database Maintenance Utilities
The Automated Database Maintenance Utilities perform common database
maintenance tasks. This enables the database administrator to spend less time
each day working with the Enterprise eTIME application database.
The Automated Database Maintenance Utilities only work with Microsoft SQL
Server (SQL Server), the RDBMS on which the Enterprise eTIME application
database resides. They perform the following tasks:
w
Maintain the SQL Server Master database, the ADP Enterprise eTIME
database, and the SQL Server transaction log
w
Automatically perform database maintenance tasks
w
Create log files that enable you to review the database status
The Automated Database Maintenance Utilities include eight maintenance jobs
that reside in a single maintenance script called mainttasks.sql. For descriptions of
these jobs, see “Job Details.”
In addition, there is a script called createdumps.sql that helps the database
administrator create database backup devices. Backup devices are logical file
structures that indicate where SQL Server must store the database backups.
The scripts are placed on the Enterprise eTIME product CD, and you can access
them after product installation. By default, the scripts reside in the following
directory:
Program Files\destination\kronoscm\DBserver\ZDBA.
destination is the name that you selected when you installed the Enterprise eTIME
system.
4-2
ADP, Inc.
System Requirements
System Requirements
The Automated Database Maintenance Utilities are designed to work with the
following system configuration:
w
Enterprise eTIME Suite Version 4.0 or later, running on Windows NT Server
Version 4.0, Service Pack 3 or later
w
Microsoft SQL Server 2000
w
2000 employees or less per database
The Enterprise eTIME system lets you schedule employees and process payroll
quickly and efficiently. The application collects information from a variety of
input devices, such as data collection timeclocks, and calculates employee hours
by comparing time data and employee schedules with the set of rules established
for that employee.
For information about Enterprise eTIME requirements, see the Enterprise eTIME
Installation Guide for Windows.
Enterprise eTIME Database Administrator’s Guide
4-3
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
Installation Checklists
The following checklists contain the database installation tasks that you must
perform and the documentation that describes how to perform the tasks.
Enterprise eTIME Database Installation Tasks
The following checklist lists the Enterprise eTIME Database installation tasks.
q
q
q
q
4-4
To perform this task
1. Install and configure Microsoft SQL Server
2000 database.
2. Build the Enterprise eTIME database.
See this documentation
SQL Server Books Online
Chapter 4 in the Enterprise eTIME
Database Installation Guide
3. Configure SQL Server Agent to start with the
operating system.
4. Configure the Enterprise eTIME database (the
default name is tkcsdb) so that the Truncate
log on Checkpoint option is disabled.
SQL Server Books Online
SQL Server Books Online
ADP, Inc.
Installation Checklists
Automated Database Maintenance Utilities Tasks
The following checklist contains the Automated Database Maintenance Utilities
installation and configuration tasks that you must perform. The following sections
describe these tasks in detail.
q
q
q
q
q
q
To perform this task
1. Analyze server disk space.
See these sections in this chapter
“Analyze Server Disk Space”
2. Create Automated Database
Maintenance Utilities directories.
3. Create SQL Server database backup
devices.
4. Install the database maintenance jobs.
“Create Backup and Log Directories”
5. Activate each job.
“Activate the Jobs”
6. Test each job.
“Test the Jobs”
“Create SQL Server Database Backup Devices”
“Install Maintenance Task Jobs”
Enterprise eTIME Database Administrator’s Guide
4-5
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
Performing Automated Database Maintenance Utilities
Tasks
The following sections detail the Automated Database Maintenance Utilities tasks
you must perform.
Analyze Server Disk Space
The Automated Database Maintenance Utilities store seven days of master and
Enterprise eTIME database backups and 24 transaction log backups. Use the
following table to ensure that the drive on which you place your database files has
adequate disk space:
Number of
Employees
Size of Data
Files (MB)
Size of
Transaction
Logs (MB)
Size of 7 Data
Backup Files
(GB)
Size of 24
Log Backup
Files (MB)
Total Disk
Space
(GB)
500
250
100
1
70
2
1000
600
150
3
70
4
2000
1200
300
5
70
7
Note
These estimates are for data accumulated over one year of history and associated
backups. Keep in mind that disk space requirements continue to increase over
time, and vary depending on the configuration of your system.
4-6
ADP, Inc.
Performing Automated Database Maintenance Utilities Tasks
Create Backup and Log Directories
By default, the system looks for the following directories to store the backup and
log files:
C:\ADP\wfcdb\backups
C:\ADP\wfcdb\logs
You must create these directories on the server. When you create the directory
structure, keep the following information in mind:
w
Try to use the default directory structure.
w
When creating backup directories, try to keep them in one place so that you
can easily back up to tape.
w
If there is not enough disk space on drive C, you can either:
w
–
Move the backup files and their directories to a different drive.
–
Create the same directory structure on different drives. For example, you
can create the ADP\wfcdb\backup and ADP\wfcdb\logs directories on
both drives C and D.
Because the log files are small, keep them in the default location.
After determining what backups to store on each drive, create the previously
mentioned directory structure on drive C and any other drives you need.
Save the directory location information. You need to refer to it when performing
the steps described in “Create SQL Server Database Backup Devices” and “Install
Maintenance Task Jobs.”
Enterprise eTIME Database Administrator’s Guide
4-7
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
Create SQL Server Database Backup Devices
Database backup devices are logical file structures that direct SQL Server where
to store database backups. The Automated Database Maintenance Utilities include
a script called createdumps.sql that is included in the zip file. This file assists you
in creating the database backup device. You must edit this file to reflect the
database name and directory location for your database installation.
To create SQL Server database backup devices:
1. Locate the scripts in kronoscm\DBserver\ZDBA.
2. Edit the createdumps.sql script to reflect your database name and directory
structure:
a. Select Start > Programs > Microsoft SQL Server > Query Analyzer.
b. In Query Analyzer, connect to the Enterprise eTIME database as the
database owner.
c. Open the file createdumps.sql by clicking the Open button
selecting the file in the dialog box.
and
d. Query Analyzer opens the script in your current window.
e. Change the database name, and log file directory location if necessary.
Follow the directions in the script’s header file, using the directory
locations you created in “Create Backup and Log Directories.”
3. Click the Execute button
devices.
to execute the script and create the backup
The script creates the backup files and the results display in the Results
window.
4-8
ADP, Inc.
Performing Automated Database Maintenance Utilities Tasks
Install Maintenance Task Jobs
The mainttasks.sql script contains maintenance tasks or “jobs.” There is a job for
each day of the week, as well as a job that maintains the SQL Server transaction
log on an hourly basis. Before you install or run these scripts, you must edit them
to reflect the database name, and, if necessary, the location for the
\ADP\wfcdb\logs directory.
To edit and install the Automated Database Maintenance jobs:
1. Select Start > Programs > Microsoft SQL Server > Query Analyzer.
2. In Query Analyzer, connect to the Enterprise eTIME database as the database
owner.
3. Click the Open button
to open the job script, then select mainttasks.sql.
Query Analyzer opens the script in your current window:
4. Change the database name, and log file directory location, if necessary.
Follow the directions in the script’s header file, using the directory locations
you created in “Create Backup and Log Directories.”
5. Click the Execute button
to execute the script. Ignore the warnings about
nonexistent steps referenced by @on_success_step_id.
Activate the Jobs
By default, the jobs do not run until you activate them. To activate each job:
1. Select Start > Programs > Microsoft SQL Server > Enterprise Manager.
2. Double-click the SQL Server Group.
3. Double-click the server.
4. Double-click the Management folder to display SQL Server Agent.
5. Click SQL Server Agent to display the Jobs icon.
6. Double-click Jobs to display the list of maintenance tasks.
7. Double-click a job to display the Job Properties dialog box.
Enterprise eTIME Database Administrator’s Guide
4-9
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
8. If necessary, change the name and description of this job.
9. Select the Enabled check box, then click OK.
10. Repeat steps 7 and 8 for the remaining jobs.
4-10
ADP, Inc.
Performing Automated Database Maintenance Utilities Tasks
Test the Jobs
To complete the installation, test each job as follows:
1. Select Start > Programs > Microsoft SQL Server > Enterprise Manager.
2. Double-click the SQL Server Group.
3. Double-click the server.
4. Double-click the Management folder to display SQL Server Agent.
5. Click SQL Server Agent to display the Jobs icon.
6. Double-click Jobs to display the list of maintenance jobs.
7. Right-click a job you want to test. Select Start Job.
The Start Job dialog box appears.
8. Click Start.
The job’s Status changes to Executing. It takes several minutes for the jobs to
run.
9. When the job finishes, review that job’s log file to determine whether the job
ran properly.
Enterprise eTIME Database Administrator’s Guide
4-11
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
Job Details
This section summarizes the tasks that the daily maintenance and transaction log
jobs perform.
Database Maintenances Jobs Description
A daily maintenance job runs at 12.05 A.M each day. The maintenance jobs are
named ADP Enterprise eTIME product installation name Database Maintenance
Plan day of the week. For example, the product installation name might be ADP
Enterprise eTIME. The day of the week is Sunday through Saturday.
Each job contains the steps summarized in the following table:
4-12
Step Number
Step Description
Step Dependency
Steps 1 through 3
Initialize the log files
None
Step 4
Master DB Backup with init
None
Step 5
Write error log and exit
Run only if Step 4 fails
Step 6
Master DB Checkdb
None
Step 7
Write error log and exit
Run only if Step 6 fails
Step 8
Master DB backup with init
None
Step 9
Write error log and exit
Run only if Step 8 fails
Step 10
TKCSDB Backup with init
None
Step 11
Write error log and exit
Run only if Step 10 fails
Step 12
TKCSDB Checkdb
None
Step 13
Restore TKCSDB database
Run only if Step 12 fails
Step 14
Write message to log and exit
Run only if Step 13 succeeds
Step 15
Write error log and exit
Run only if Step 13 fails
Step 16
TKCSDB rebuild indexes
None
Step 17
Restore TKCSDB database
Run only if Step 16 fails
Step 18
Write message to log and exit
Run only if Step 17succeeds
Step 19
Write error log and exit
Run only if Step 17 fails
ADP, Inc.
Performing Automated Database Maintenance Utilities Tasks
Step Number
Step Description
Step Dependency
Step 20
TKCSDB Shrinkdb
None
Step 21
Restore TKCSDB database
Run only if Step 20 fails
Step22
Write message to log and exit
Run only if Step 21 succeeds
Step23
Write error log and exit
Run only if Step 21 fails
Step 24
TKCSDB Backup with init
None
Step 25
Write error log and exit
Run only if Step 24 fails
Step 26
Initialize transaction log with init
None
Step 27
Write error log and exit
Run only if Step 26 fails
Step 28 through 29 Write job completion messages to None
log
Transaction Log Maintenance Job Description
The transaction log maintenance job runs every hour, starting at 2 A.M. and
ending at 11.45 P.M each day.
The job contains the following step:
Step Number
Step Description
Step Dependency
Step 1
Dump transaction log (appends
current log)
None
Enterprise eTIME Database Administrator’s Guide
4-13
Chapter 4
Installing and Configuring Automated SQL Server Database Maintenance Utilities Scripts
Viewing Jobs
You can view the following information about jobs in the Job Properties dialog
box.
Tab
General
Information
Job name, category, owner, description,
and activation state (Enabled)
Steps
Step ID, name, type, and activities on
success or failure
Job ID, name, activation state,
description, and current date and time
Indicate the actions to perform when
the job completes
Schedules
Notifications
Action
Change the job’s name, category,
description, owner, or enable or disable
the job.
Insert, edit, or delete steps.
Create a new schedule or alert, edit the
existing schedule, or delete the job.
Send e-mail or page when the job
succeeds, fails, or completes.
To view information about jobs:
1. Select Start > Programs > Microsoft SQL Server > Enterprise Manager.
2. Double-click the SQL Server Group.
3. Double-click the server.
4. Double-click the Management folder to display SQL Server Agent.
5. Click SQL Server Agent to display the Jobs icon.
6. Double-click Jobs to display the list of maintenance jobs.
7. Double-click the Management folder to display SQL Server Agent.
8. Click SQL Server Agent to display the Jobs icon.
9. Double-click Jobs to display the list.
10. Double-click a job to display the Job Properties dialog box.
4-14
ADP, Inc.
Chapter 5
Maintaining the SQL Server Database with
Automated Database Maintenance Utilities
This chapter describes how to use the Automated Database Maintenance Utilities
to maintain your Enterprise eTIME SQL Server database. It includes the
following sections:
w
Database Tasks
w
Review the Maintenance Log Files
w
Back Up the Database Files
Chapter 5
Maintaining the SQL Server Database with Automated Database Maintenance Utilities
Database Tasks
Each day, you must perform the following daily database tasks:
w
Review the daily maintenance log file.
w
Back up the database backup and log files.
Use the following checklist to help you keep track of your database maintenance
tasks:
5-2
q
q
q
1. Review the daily maintenance log file.
q
4. If the maintenance job completed successfully, back up the database directory
and files.
2. Determine if the database is operational.
3. If problems occurred, gather troubleshooting information and contact TLM
Support:
w Job’s backup log
w SQL Server logs
w Windows NT System and Application files
ADP, Inc.
Review the Maintenance Log Files
Review the Maintenance Log Files
Each ADP maintenance job creates two logs after the job completes. The logs
resides in the directory that you specified as described in “Create SQL Server
Database Backup Devices” in Chapter 4, and are named for the days of the week.
For example, monday.log and sqloutput_monday.log are the names of the logs
created by the job that runs early on Monday morning. By default, the log files
reside in c:\ADP\wfcdb\logs.
Review the day of the week.log file to ensure that the database is running properly.
When you review the day of the week.log file, you need only check the last line in
the file that begins with three asterisks (***).
The sqloutput_ day of the week file contains troubleshooting information that your
TLM Representative uses if a problem occurs. You do not need to review this log
file.
Enterprise eTIME Database Administrator’s Guide
5-3
Chapter 5
Maintaining the SQL Server Database with Automated Database Maintenance Utilities
After reviewing the log, you must perform one of the following tasks:
w
If the daily job completes successfully, back up that day’s files using the
Windows NT Backup Utility as described in “Back Up the Database Files.”
w
If any job’s step in the daily script ends in failure or with an error, or there is
no message at all, you must gather the information that helps TLM Support
determine why the step failed. To do this, review the error message in the log
file’s last line as described in “Review the Maintenance Job Messages.”
Review the Maintenance Job Messages
Each daily job consists of a series of steps. Each step performs a database
function. If any problem occurs, the maintenance job creates a message that
identifies the step at which the problem occurs and the state of the database.
Database Maintenance Messages
After each maintenance job completes, a message appears at the end of the job’s
log file. If the job runs successfully, the following message appears:
*** WFC Database Maintenance Plan for [day of the week]
has successfully completed.
The variable day of the week is the day on which the maintenance job ran.
If the job is not successful, the error messages assist you in determining the source
of the problem. Automated Database Maintenance job error messages include the
following information:
w
The job step at which the error occurred
w
The nature of the error or failure
w
Whether the database is available for use
The following error conditions can occur:
5-4
w
The backup fails, but the database is available for use.
w
A job runs into problems and attempts to restore the database. It successfully
restores the database, and the system is available for use.
ADP, Inc.
Review the Maintenance Log Files
w
A job runs into problems and attempts to restore the database. It is unable to
restore the database, and the system is not available for use.
w
On occasion, no message appears at the end of the log file. This indicates that
the job did not finish. For example, this can result when a power failure
occurs and the system shuts down improperly. Contact TLM Support to fix
the problem.
Error State Examples
Here are two examples of common situations that generate errors.
Example 1
The Friday maintenance job runs.
w
Step 4 attempts to back up the master database without success.
w
Step 5 produces the following error message in the log file:
*** Step 4- Master DB Backup 1 Failed -Database is
available for use.
Although the operation failed, the database is still available. However, because
master database backups are important for disaster recovery, TLM Support must
determine why the backup failed.
Example 2
The Saturday maintenance job runs:
w
Step 11 attempts to back up the Enterprise eTIME database without success.
w
Step 12 attempts to run the checkdb utility without success.
w
Step 13 attempts to restore the database without success and produces the
following error message in the log file:
*** Step 12 - WFC DB Checkdb Failed - Attempted
database restore failed - database is unavailable for
use.
TLM Support must assist you in restoring the database.
Enterprise eTIME Database Administrator’s Guide
5-5
Chapter 5
Maintaining the SQL Server Database with Automated Database Maintenance Utilities
The following table summarizes the messages that can appear at the bottom of the
log file:
Message
*** WFC Database Maintenance Plan for day of the week has successfully completed.
Please backup all log and database backup files to external media***
*** Step 4 - Master DB Backup 1 Failed - Database is available for use.
*** Step 6 - Master DB Checkdb Failed - System is unavailable.
*** Step 8 - Master DB Backup 2 Failed - Database is available for use.
*** Step 10 - WFC DB Backup 1 Failed - Database is available for use.
*** Step 12 - WFC DB Checkdb Failed - Attempted database restore
successful - database available for use.
*** Step 12 - WFC DB Checkdb Failed - Attempted database restore failed database is unavailable for use.
*** Step 16 - WFC DB Rebuild Indexes Failed - Attempted database restore
successful - database is available for use.
*** Step 16 - WFC DB Rebuild Indexes Failed - Attempted database restore
failed - database is unavailable for use.
*** Step 16 - WFC DB Rebuild Indexes Failed - Attempted database restore failed database is unavailable for use.
*** Step 20 - WFC DB Shrink DB Failed - Attempted database restore failed database is unavailable for use.
*** Step 24 - WFC DB Backup 2 Failed - Database is available for use.
*** Step 26 - WFC DB Initialize Transaction Log Backup Failed - Database is
available for use.
5-6
ADP, Inc.
Review the Maintenance Log Files
Database Log File Information
Database log and backup files usually reside in the following directories:
Enterprise eTIME Files
C:\ADP\wfcdb\backups
C:\ADP\wfcdb\logs
SQL Server Files
C:\Program Files\Microsoft SQL
Server\Mssql\backup
C:\Program Files\Microsoft SQL
Server\Mssql\log
TLM Support needs these log files when troubleshooting database problems.
Windows NT System and Application Logs
In addition to database files, you need to gather information about the Windows
NT server to assist TLM Support in troubleshooting system problems.
Use the Event Viewer to access the logs that record activities that occur on the
server. The Event Logging service starts automatically when your Windows NT
server starts and keep tracks of these activities.
To save copies of Windows NT System and Application logs:
1. Select Start > Programs > Administrative Tools > Event Viewer to display
the Event Viewer window.
2. Select Log > System from the menu bar.
The System log appears.
3. Select Log > Save As from the menu bar to display the Save As dialog box.
4. Select a directory location and enter a name for the log. Remember the name
and location so that you can access the log later.
5. Select Log > Application from the menu bar.
The System log appears.
6. Repeat steps 3 and 4.
Enterprise eTIME Database Administrator’s Guide
5-7
Chapter 5
Maintaining the SQL Server Database with Automated Database Maintenance Utilities
Back Up the Database Files
Backing up your database files is an important task that allows you to provide
proper disaster recovery. You must back up all logs and database backups to tape
each day after the maintenance job successfully runs. If the maintenance job log
contains errors as described in “Database Maintenance Messages,” contact TLM
Support.
By default, the database logs and backups are stored in the following directories:
w
C:\ADP\wfcdb\logs
w
C:\ADP\wfcdb\backups
If your database directories reside in different locations (for example, drive D), go
to those locations when backing up the files.
Note
Before you back up the database files, make sure the tape drive is installed on or
connected to the database server. See your system administrator for information
about setting up tape drives.
To back up the database files, run the Windows NT Backup utility, as follows:
1. Insert the tape into the tape drive.
2. Selecting Start > Programs > Administrative Tools (Common) > Backup
to access the Backup Utility. The Backup window appears.
3. Make sure that you select the Drives window.Double-click drive C (or the
drive on which the wfcdb log and backup files reside).
The directory structure appears.
Note
If the database backup or log files reside in more than one directory and/or on
more than one drive, you must select all the directory locations.
5-8
ADP, Inc.
Back Up the Database Files
4. Select the check box next to \ADP\wfcdb. Doing so includes the logs and
backups directories within the wfcdb directory.
5. Click the Backup button.
After backing up the files, the Backup Utility displays a message that the
backup successfully completed.
6. Select Exit from the Operations menu.
7. Remove the tape from the tape drive and label it appropriately.
See the Windows NT Backup Help for detailed information about Windows NT
backups.
Enterprise eTIME Database Administrator’s Guide
5-9
Chapter 5
5-10
Maintaining the SQL Server Database with Automated Database Maintenance Utilities
ADP, Inc.
Index
A
ADD DATAFILE option 2-26
ADD LOGFILE GROUP option 2-33
ADD LOGFILE MEMBER option 2-34
adding datafiles
ALTER TABLESPACE command 2-26
to a tablespace 2-26
adding log file group to existing database 2-33
adding redo log file to existing log group 2-34
advanced queuing (Oracle option) 2-8
ALTER DATABASE command
ADD LOGFILE GROUP 2-33
ADD LOGFILE MEMBER 2-34
BACKUP 2-42
CLEAR UNARCHIVED LOGFILE
GROUP 2-61
DROP LOGFILE GROUP 2-34
DROP LOGFILE MEMBER 2-34
RECOVER AUTOMATIC 2-52, 2-53
RECOVER AUTOMATIC FROM 2-53
RECOVER CONTINUE DEFAULT 2-53
RECOVER DATAFILE 2-52
RECOVER LOGFILE 2-53
RECOVER TABLESPACE 2-52
ALTER ROLLBACK SEGMENT command
ONLINE 2-24
to place segment online 2-25
ALTER SYSTEM command 2-48
ARCHIVE ALL 2-41
ARCHIVE LOG CURRENT 2-48, 2-49
ARCHIVE LOG START 2-37, 2-49
ARCHIVE LOG STOP 2-49
ARCHIVE LOG TO 2-37
CHECK DATAFILES 2-62
ENABLE RESTRICTED SESSION 2-21
ALTER TABLESPACE command
ADD DATAFILE 2-26
adding datafiles 2-26
BEGIN BACKUP 2-42
COALESCE 2-68
END BACKUP 2-42
OFFLINE FOR RECOVER 2-56
ONLINE option 2-25
RENAME DATAFILE 2-56, 2-57
alternate archive destination 2-55
alternate backup strategies 2-59
ANALYZE TABLE statement
COMPUTE STATISTICS 2-69
VALIDATE REF UPDATE option 2-61
ARCH process 2-7, 2-33, 2-38
database hangs 2-63
LOG_BLOCK_CHECKSUM
parameter 2-61
operation of 2-38
running out of space 2-49
slave processes for 2-47
starting 2-37
ARCHIVE LOG command
ALL option 2-55
CURRENT option 2-48
NEXT option 2-55
STOP option 2-55
Index
archive log space
area unavailable 2-55
running out of space 2-48
archived redo logs 2-5, 2-36
backing up 2-41
restoring datafiles 2-56
with inconsistent backups 2-42
ARCHIVELOGMODE 2-7, 2-36
online backups 2-42
partial backups with 2-41
archiver process (ARCH). See ARCH process
archiving
automatic
illustration 2-38
changing destination 2-48, 2-55
destination 2-37
privileges for 2-48
specifying a second destination 2-37
starting in parameter file 2-37
stopping 2-55
strategies for Oracle 2-37
archiving, automatic
operation of 2-38
stopping 2-49
archiving, manual 2-37
ARCHIVE LOG ALL 2-55
ARCHIVE LOG NEXT 2-55
clearing logs 2-39
Auto Start Server at Boot Time option 3-5
Automated Database Maintenance Utilities 4-2
backup devices 4-8
backups 5-8
database tasks 5-2
disk space requirements 4-6
installation checklist 4-5
maintenance jobs 4-9
descriptions 4-12
error examples 5-5
messages 5-4
mainttask.sql script 4-9
Index-2
performing maintenance 5-1
requirements 4-3
review maintenance job messages 5-3
review maintnance logs 5-2
troubleshooting with Windows NT 5-7
viewing jobs 4-14
automatic archiving
operation of 2-38
stopping 2-55
automating backups 3-34
B
background processes 2-7
at database start 2-19
implementation 2-8
shared pool for 2-9
BACKUP DATABASE statement
steps 3-22
using 3-19
with temporary backup devices 3-17
backup devices
Automated Database Maintenance
Utilities 4-8
defining 3-16, 3-17
for Enterprise eTIME database 3-15
tape 3-20
temporary 3-17
backup files
definition of 3-15
backup strategies 1-9
for master database 3-18
for online redo logs 2-41
for Oracle databases 2-41
BACKUP TRANSACTION statement, with
temporary backup devices 3-17
backups
ARCHIVE ALL 2-41
archived redo logs 2-41
Automated Database Maintenance
Utilities 5-8
ADP, Inc.
Index
automating 3-34
cold 2-41
control files 2-41
datafiles 2-41
frequency 1-9
full 1-8
hot 2-42
inconsistent 2-42
incremental 1-8, 3-20
logical. See Export utility
Maintenance Plan Wizard 3-34
master database 3-18
of closed database 2-42
of control files 2-14, 2-42
of individual tablespaces 2-42
of online redo logs 2-41
offline (cold) 2-41
online (hot) 2-42
parameter files 2-41
partial 2-47
password files 2-41
preliminary procedures 3-18
reasons for 1-7
rollback tablespaces 2-47
scheduling 3-34
strategies 1-9
terminology 1-8
transaction logs 3-20
types 1-8
when to perform 3-18
batch files, for backup 3-34
broadcasting a shutdown message 3-6
building maintenance schedules 1-10
C
CATALOG.SQL 2-16, 2-18
CATDBSYN.SQL 2-18
CATPROC.SQL 2-16, 2-18
chained records in Oracle 2-13
changing archive destination 2-55
Enterprise eTIME Database Administrator’s Guide
changing the MSSQLServer startup
parameters 3-5
CHECK DATAFILES option 2-62
Checkdb DBCC command 3-29
before backup 3-18
checkpoint process (CKPT). See CKPT process
checkpoints 2-14
and log reuse 2-32
DBWR 2-31
entry in control file 2-32
managing 2-32
on recovery 3-23
on shutdown 2-32, 3-7
Oracle 2-31
system global area 2-31
timing out 2-33
truncate log in SQL Server 3-20
checksum errors 2-61
CKPT process 2-7, 2-32
checkpoints 2-32
COMPUTE STATISTICS option 2-69
config.ora files 2-12
configuration parameters
BACKGROUND_DUMP_DEST 2-63
DB_BLOCK_MAX_DIRTY_TARGET
values 2-59
DB_BLOCK_SIZE 2-13
in other files 2-12
LOG_ARCHIVE_DEST 2-37, 2-53
LOG_ARCHIVE_DUPLEX_DEST 2-37
LOG_ARCHIVE_FORMAT 2-53
LOG_ARCHIVE_START 2-37
LOG_BLOCK_CHECKSUM 2-61
LOG_CHECKPOINT_INTERVAL 2-32,
2-33
LOG_CHECKPOINT_TIMEOUT 2-32,
2-33
LOG_FILES 2-36
MAXLOGFILES 2-33, 2-36
MAXLOGMEMBERS 2-36
Index-3
Index
OPTIMIZER_MODE 2-69
specifying 2-12
configuring
SQL Server 2000 3-5
CONSISTENT export parameter 2-45
consistent whole backup 2-41
control files
ALTER DATABASE BACKUP
CONTROLFILE 2-42
at database startup 2-19
backing up 2-14, 2-41, 2-42
checkpoint entry 2-32
contents of 2-13
creation of 2-13
definition 2-4
managing 2-13
mounting the database 2-19
multiplexing 2-14
permanent damage 2-58
shutting down corrupt 2-14
unavailable 2-54
using backup control file 2-58
CONTROLFILE option 2-42
creatddl.sql file 3-33
CREATE DATABASE statement, on Oracle
UNIX 2-16
CREATE PUBLIC ROLLBACK SEGMENT
command 2-24
CREATE ROLLBACK SEGMENT
command 2-25
CREATE TABLESPACE command 2-25
create.sql file 3-33
creating
backup devices 3-16
data tablespaces 2-25
log groups 2-33
parameter files 2-12
redo log files 2-33
SQL Server filegroups 3-12
system rollback space 2-24
Index-4
tablespaces 2-25
temporary backup devices 3-17
temporary tablespaces 2-26
Enterprise eTIME database on Oracle
NT 2-14, 2-16
Enterprise eTIME database on SQL Server
2000 3-8
Enterprise eTIME database on UNIX 2-17
cropping, indexes 2-65
current redo log 2-28
D
data blocks
coalescing free space 2-68
format of 2-23
free space in 2-23
in database buffer cache 2-9
in logical structure 2-5
data dictionary
cache 2-9
taking offline 2-27
data segments 2-22
database administrator job functions 1-4
database buffer cache 2-9
database checkpoints 2-31
database hangs, correcting 2-33
database identifier, in NT Instance Manager
Graphical interface 2-16
database initialization parameters. See
configuration parameters
database instance. See instance
Database Maintenance Plan Wizard 3-29
database options 3-10
truncate log on checkpoint 3-20
database records, chaining in Oracle 2-13
database server, software for 1-2
Database Writer process (DBWR). See DBWR
process
ADP, Inc.
Index
databases
creating on SQL Server 2000 3-8
database instance 2-4
deleting 3-27
managing files and filegroups 3-8
Oracle 2-4
Oracle components 2-10
Oracle structure 2-4, 2-5
record chaining in Oracle 2-13
recovering 2-52
recovering from alternate location 2-53
recovering lost control files 2-58
re-creating for restore 3-27
restoring 3-24
shutting down 2-21
starting in restricted mode 2-20
tablespace distribution 2-22
datafiles
adding 2-26
backing up 2-41
definition 2-5
determining if recovery is needed 2-53
RECOVER DATAFILE 2-52
recovering in SYSTEM tablespace 2-54
recovering in user tablespace 2-55
relation to tablespaces 2-5
restoring to alternate location 2-56, 2-57
SQL Server 2000 3-8
DB_BLOCK_SIZE configuration
parameter 2-13
DBA_DATA_FILES view 2-56, 2-57
DBA_FREE_SPACE_COALESCED
view 2-68
DBCC commands 3-29
Checkdb 3-29
Dbreindex command 3-32
DBReport utility 1-6
reading output 3-30
SQL Server 3-30
Enterprise eTIME Database Administrator’s Guide
DBWR process 2-7
checkpoints 2-31
slave processes 2-33
trace file 2-55
DDL scripts 1-6
DEFAULT STORAGE clause
of CREATE TABLESPACE command 2-26
defining and using server groups 3-4
deleting databases 3-27
dependent objects
dropping 3-33
re-creating 2-66, 3-33
distributed databases (Oracle option) 2-8
drop.sql 2-66, 3-33
dropddl.sql 2-66
dropping
dependent objects 2-66, 3-33
indexes 3-33
objects during maintenance 2-51
redo log files or log groups 2-34
rollback segments 2-55
E
ENABLE RESTRICTED SESSION 2-21
enabling a restricted session 2-21
Enterprise eTIME database
backup devices for 3-15, 3-16
components in Oracle 2-10
configuation parameters for Oracle 2-13
creating filegroups for 3-12
creating on Oracle NT 2-14, 2-16
creating on SQL Server 2000 3-8
creating on UNIX 2-17
creating tablespaces for 2-25
creating with NT Instance Manager 2-14
dropping indexes 3-33
exporting the schema 2-46
integrity checking 3-29
redo logs for 2-36
SQL Server backup devices 3-16
Index-5
Index
tablespace distribution 2-22
taking tablespaces offline 2-27
temporary backup devices 3-17
errors
ORA-09352 2-17
ORA-12154 2-17
SQL Server error 1105 3-12
exp command (Export utility) 2-46
EXP_FULL_DATABASE role 2-45
export
characteristics 2-44
complete 2-44
cumulative 2-44
incremental 2-44
export parameters
CONSISTENT 2-45
FILE 2-45
FULL 2-44, 2-45
GRANTS 2-45
INCTYPE 2-45
INDEXES 2-45
USER 2-46
Export utility
command line 2-46
exp command 2-46
EXP_FULL_DATABASE role 2-45
for logical backups 2-43
help for 2-46
required rights 2-45
transfering files across systems 2-45
using 2-46
exporting the Enterprise eTIME schema 2-46
extents 2-22
default storage clause 2-23
in segments 2-5
incremental 2-23
F
FILE export parameter
filegroups 3-8
Index-6
2-45
creating in SQL Server 2000 3-12
managing 3-12
sp_helpfilegroup 3-13
files
sp_helpfile 3-13
transaction log 3-11
Free space 2-13
free space
coalescing 2-68
determining need for COALESCE 2-68
in data blocks 2-23
full backup 1-8
using SQL Server Enterprise Manager 3-19
using SQL statements 3-19
FULL export parameter 2-45
G
GRANTS export parameter
2-45
H
hot backups 2-42, 3-23
ARCHIVELOGMODE
2-42
I
import 2-60
resetting ROWID values 2-61
inconsistent closed database backups 2-42
inconsistent whole database backup 2-42
incremental backups 1-8, 3-20
in SQL Server Enterprise Manager 3-21
using SQL statements 3-21
with nonlogged operations 3-20
incremental exports 2-44
incremental extents 2-23
INCTYPE export parameter 2-45
indexes
dropping 3-33
rebuilding 2-65, 3-32
ADP, Inc.
Index
re-creating 3-33
segments 2-22
INDEXES export parameter 2-45
init*.ora files 2-12
after control file loss 2-58
initialization parameters. See configuration
parameters
instance
definition of 2-4
recovery 2-50
recovery steps 2-51
starting services automatically 2-15
structure of 2-6
integrity checking 1-11, 3-29
J
jobs, viewing
4-14
L
LGWR process 2-7
database hangs 2-63
log switches 2-29
reusing log files 2-29
running out of space 2-32
with ARCH 2-7
with automatic archiving 2-38
with committed transactions 2-9
with full redo log buffer 2-9
with log groups 2-31
writing to redo log files 2-28
library cache, contents of 2-9
log files
creating 2-33
log files, multiplexed 2-30
log groups
adding 2-33
adding redo log files 2-34
creating 2-33
dropping 2-34
log sequence number 2-31
Enterprise eTIME Database Administrator’s Guide
log switching 2-29, 2-31
with redo log groups 2-30
Log Writer process (LGWR). See LGWR process
LOG_ARCHIVE_DEST configuration
parameter 2-37, 2-53
changing 2-48
LOG_ARCHIVE_DEST, archiving
strategies 2-37
LOG_ARCHIVE_DUPLEX_DEST
configuration parameter 2-37
LOG_ARCHIVE_FORMAT configuration
parameter 2-53
LOG_ARCHIVE_START configuration
parameter 2-37
LOG_BLOCK_CHECKSUM configuration
parameter 2-61
LOG_CHECKPOINT_INTERVAL
configuration parameter 2-32, 2-33
LOG_CHECKPOINT_TIMEOUT configuration
parameter 2-32, 2-33
LOG_FILES configuration parameter 2-36
logical backups 2-40, 2-43
M
maintenance jobs
details 4-12
error examples 5-5
installing for Automated Database
Maintenance Utilities 4-9
messages 5-4
reviewing 5-3
testing 4-11
Maintenance Plan Wizard 3-34
mainttasks.sql script 4-9
managing
control files 2-13
filegroups 3-12
parameter files 2-12
master database
backing up 3-18
Index-7
Index
backing up with TRUNCATE_ONLY 3-22
backup strategies for 3-18
contents of 3-18
DBCC commands for 3-29
recovering 3-27
recovering from complete backup 3-25
MAXLOGFILES configuration
parameter 2-33, 2-36
MAXLOGMEMBERS configuration
parameter 2-36
media recovery 2-52
mirrored log files. See log groups
mounting the database 2-19
MSSQLServer service
changing startup parameters 3-5
shutting down 3-6
startup parameters for 3-5
multiplexing
control files 2-14
log files 2-30
multithreading (Oracle option)
2-8
N
net send/users command 3-6
NET*8
setting up 2-17
UNIX 2-18
network communications software
setting up in Oracle NT 2-17
setting up in UNIX 2-18
NOARCHIVELOGMODE, and redo logs 2-28
NOMOUNT startup option 2-21
nonlogged operations, with incremental
backup 3-20
NT Instance Manager
creating Oracle databases 2-14
getting help for 2-15
graphical interface 2-16
starting database from 2-20
Index-8
syntax 2-14
NT Services panel
to configure SQL Server
3-6
O
offline (“cold”) backups 2-41
offline redo logs. See archived redo logs
online (“hot”) backups. See backups
ONLINE option, of ALTER ROLLBACK
SEGMENT command 2-25
online redo logs
applying 2-53
archived 2-36
backing up 2-41
definition 2-5
maximum files allowed 2-33
recovering corrupt 2-61
running out of logs 2-47
Optimizer
Oracle 2-68
OPTIMIZER _MODE configuration
parameter 2-69
ALL_ROWS 2-69
FIRST_ROWS 2-69
ora*.cfg files 2-12
Oracle databases
components of 2-10
creating on Windows NT 2-16
logical structure of 2-5
shutting down 2-21
structure 2-4
Oracle Parallel Server 2-8
Oracle processes 2-6
Oracle template file, default location 2-12
ORACLE_HOME logical name 2-12
OracleServiceSID 2-17
OracleStartSID 2-17
ORADIM80 2-15
ADP, Inc.
Index
P
parameter files
at database startup 2-19
backing up 2-41
creating 2-12
definition 2-4
definition of 2-12
for export 2-44
managing 2-12
naming conventions for 2-12
parameters for Enterprise eTIME
database 2-13
required parameters 2-13
specifying DB_BLOCK_SIZE 2-13
template file for 2-12
partial backups 2-47
password files, backing up 2-41
PCTINCREASE 2-68
physical backups 2-40
contents of 2-40
full 2-40
partial backups 2-41
physical storage structure, Oracle 2-4
privileges
changing archive destination 2-48
Process Monitor (PMON) process 2-7
processes, Oracle 2-6
production databases
damage to 1-7
upgrade failures 1-7
viruses 1-7
Program Global Area (PGA) 2-6
PUPBLD.SQL 2-16, 2-18
Q
Query Analyzer
database management 3-7
login window 3-7
Enterprise eTIME Database Administrator’s Guide
main window
3-7
R
Recomp utility 1-6
Oracle 2-70
recompiling stored procedures 1-11, 2-70
RECOVER DATABASE command, USING
BACKUP CONTROLFILE 2-58
recovering
corrupt online redo logs 2-61
datafiles 2-52
datafiles in SYSTEM tablespace 2-54
datafiles in user tablespace 2-55
entire database 2-52
from alternate location 2-53
log files 2-53
lost control file 2-58
master database 3-27
missing online redo logs files 2-55
online redo logs 2-53
tablespaces 2-52, 2-56
unavailable control file 2-54
recovery
automatic 3-24
checkpoints with 3-23
datafiles needed 2-53
instance 2-50
media 2-52
point-in-time 3-26
strategies 1-9, 2-54
re-creating
databases 3-27
SQL Server 2000 3-27
dependent objects 2-66, 3-33
dropped objects 3-33
indexes 3-33
redo log files or log groups 2-34
recreating
lost database 2-58
Index-9
Index
redo log buffer 2-28
definition of 2-9
full 2-9
redo log files 2-28
adding to log group 2-34
checkpoints 2-32
dropping 2-34
recovering 2-55
sequence 2-28
size for database 2-36
redo log groups
creating 2-33
log switching with 2-30
losing 2-47
redo logs
creating 2-33
current 2-28
dropping and re-creating 2-34
in NOARCHIVELOGMODE 2-28
INVALID status 2-35
location of 2-33
operation of 2-28
STALE status 2-35
RENAME DATAFILE 2-56, 2-57
resetting ROWID values 2-61
restoring
tablespaces 2-57
through a complete backup 3-25
restoring databases
preparing for 3-24
when the database must be re-created 3-27
when the database must be recreated 2-58
restricted session
enabling 2-21
starting 2-20
rights
for export 2-45
rollback segments 2-22
dropping after failure 2-55
failure 2-55
Index-10
number needed 2-25
placing online 2-24, 2-25
restoring 2-57
rollback tablespaces
backup frequency 2-47
names for 2-24
placing online 2-25
size of 2-24
S
schema objects, Oracle 2-5
segments
extents for 2-5
for data 2-22
in tablespaces 2-5, 2-22
index 2-22
kinds of 2-22
rollback 2-22
temporary 2-22
Server Manager
creating databases on UNIX 2-17
multiple connections at shutdown 2-22
SHUTDOWN command 2-21
starting a database 2-20
servers
processes 2-6
registering in SQL Server Enterprise
Manager 3-4
Service Name errors 2-17
shared pool 2-9
SHUTDOWN command 2-21
ABORT 2-21
checkpoints 2-32
IMMEDIATE 2-21
NORMAL 2-21
Server Manager 2-21
with corrupt control file 2-14
WITH NOWAIT 3-7
shutting down
broadcasting message 3-6
ADP, Inc.
Index
corrupt control file 2-14
databases 2-21
MSSQLServer service 3-6
SQL Server from the Enterprise Manager
SID, in parameter file name 2-12
SMON process
during instance recovery 2-51
functions 2-7
tablespace coalescence 2-68
sp_helpfile 3-13
sp_helpfilegroup 3-13
SQL Server 2000
Automated Database Maintenance
Utilities 4-2
configuring 3-5
filegroups 3-12
sequence to stop 3-6
starting in single user mode 3-28
SQL Server Enterprise Manager 3-3
scheduling backups 3-34
3-6
SQL*NET
setting up 2-17
UNIX 2-18
starting a database
account for 2-20
for normal use 2-20
from NT Instance Manager 2-20
in restricted mode 2-20
starting SQL Server 2000
automatically at start time 3-5
in single user mode 3-28
starting SQL Server from the Enterprise
Manager 3-5
starting the SQL Agent 3-5
STARTUP command
account for 2-20
NOMOUNT 2-21
NT Instance Manager 2-20
Server Manager 2-20
Enterprise eTIME Database Administrator’s Guide
with no parameters 2-20
without opening database 2-20
startup parameters
changing MSSQLServer 3-5
MSSQLServer 3-5
Stats utility 1-6, 2-69
Oracle 2-68
stored procedures
recompiling 1-11
System Change Number (SCN) 2-9
System Global Area
at database start 2-19
checkpoints 2-31
contents of 2-9
parts of 2-8
System Monitor (SMON) process. See SMON
process
system rollback space, creating 2-24
SYSTEM tablespace
backup frequency 2-47
lost datafile 2-54
permanent loss 2-57
T
tablespaces
adding datafiles 2-26
backing up separately 2-42
coalescing free space 2-68
creating 2-25
datafiles in 2-5
distribution for database 2-22
in logical structure 2-5
loss of SYSTEM tablespace 2-57
placing online 2-25
recovering 2-52
recovering datafiles 2-55
syntax for creating 2-25
taking offline 2-27
taking offline for recovery 2-56
Index-11
Index
temporary 2-26
task driver errors 2-17
temporary backup devices 3-17
temporary segments 2-22
TNS errors 2-17
transaction logs
backing up 3-20
disk space requirements 3-11
managing 3-11
too full 3-22
troubleshooting Automated Database
Maintenance Utilities 5-7
TRUNCATE_ONLY option 3-22
U
updating statistics
Oracle 2-68
USER export parameter
user processes 2-6
shared pool for 2-9
2-46
V
V$DATAFILE view 2-53
V$LOG view 2-34, 2-35
V$LOGFILE view 2-35
V$RECOVER_FILE view 2-53
V$SESSION_WAIT view 2-63
VALIDATE REF UPDATE, to update ROWID
values 2-61
viruses 1-7
W
whole database backup, restoring missing files
from 2-56
Windows scheduling facility 3-34
WITH NO _INFOMSGS (DBCC option) 3-29
Index-12
ADP, Inc.