* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Enterprise eTIME Database Administrator`s Guide
Survey
Document related concepts
Commitment ordering wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Serializability wikipedia , lookup
Functional Database Model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Oracle Database wikipedia , lookup
Concurrency control wikipedia , lookup
Versant Object Database wikipedia , lookup
Relational model wikipedia , lookup
Database model wikipedia , lookup
Transcript
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.