Database Administrators Guide

Database Administrators Guide
A database administrators guide to the Workforce Central system.
Kronos Workforce Central Suite Version 6.3
Document Revision: A
The information in this document is subject to change without notice and should not be construed as a commitment by Kronos Incorporated. Kronos Incorporated assumes no responsibility for any errors that may appear in this manual. This document or any part thereof may not be reproduced in any form without the written permission of Kronos Incorporated. All rights reserved. Copyright 2011. Altitude, Altitude Dream, Cambridge Clock, CardSaver, Datakeeper, Datakeeper Central, eForce, Gatekeeper, Gatekeeper Central, Imagekeeper, Jobkeeper Central, Keep.Trac, Kronos, Kronos Touch ID, the Kronos logo, My Genies, PeoplePlanner, PeoplePlanner & Design, Schedule Manager & Design, ShiftLogic, ShopTrac, ShopTrac Pro, StarComm, StarPort, StarSaver, StarTimer, TeleTime, Timekeeper, Timekeeper Central, TimeMaker, Unicru, Visionware, Workforce Accruals, Workforce Central, Workforce Decisions, Workforce Express, Workforce Genie, and Workforce TeleTime are registered trademarks of Kronos Incorporated or a related company. Altitude MPP, Altitude MPPXpress, Altitude Pairing, Altitude PBS, Comm.Mgr, CommLink, DKC/Datalink, eDiagnostics, Experts at Improving the Performance of People and Business, FasTrack, Hireport, HR and Payroll Answerforce, HyperFind, Kronos 4500 Touch ID, Kronos 4500, Kronos 4510, Kronos Acquisition, Kronos e-Central, Kronos InTouch, Kronos KnowledgePass, Kronos TechKnowledgy, KronosWorks, KVC OnDemand, Labor Plus, Momentum Essentials, Momentum Online, Momentum, MPPXpress, Overall Labor Effectiveness, Schedule Assistant, Smart Scheduler, Smart View, Start Quality, Start WIP, Starter Series, StartLabor, TeleStaff, Timekeeper Decisions, Timekeeper Web, VisionPlus, Winstar Elite, WIP Plus, Workforce Absence Manager, Workforce Acquisition, Workforce Activities, Workforce Analytics, Workforce Attendance, Workforce Central Portal, Workforce Connect, Workforce Employee, Workforce ESP, Workforce Forecast Manager, Workforce HR, Workforce Leave, Workforce Manager, Workforce MobileTime, Workforce Operations Planner, Workforce Payroll, Workforce Record Manager, Workforce Recruiter, Workforce Scheduler, Workforce Smart Scheduler, Workforce Tax Filing, Workforce Timekeeper, Workforce View, and Workforce Worksheet are trademarks of Kronos Incorporated or a related company. The source code for Equinox is available for free download at www.eclipse.org. 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 Kronos products, customers should ensure that they comply with the applicable requirements of federal and state law, such as the Fair Labor Standards Act. Nothing in this Guide shall be construed as an assurance or guaranty that Kronos products comply with any such laws. Published by Kronos Incorporated 297 Billerica Road, Chelmsford, Massachusetts 01824-4119 USA Phone: 978-250-9800, Fax: 978-367-5900 Kronos Incorporated Global Support: 1-800-394-HELP (1-800-394-4357) For links to information about international subsidiaries of Kronos Incorporated, go to http://www.kronos.com Document Revision History Document Revision A Product Version 6.3 Release Date December 2011
Contents
Chapter 1: Introduction About the database ...................................................................................... 11 DBA goals in the suite environment ........................................................... 12 Utilities and scripts ...................................................................................... 14 Reviewing table storage .............................................................................. 15 Performance of Import jobs .................................................................. 16 Backup and recovery ................................................................................... 17 Reasons to perform backups ................................................................. 17 Reasons you may be unable to back up your database ......................... 18 Restoring a different copy of the database ............................................ 18 Types of backup .................................................................................... 19 Backup and recovery strategy ............................................................... 19 Building a maintenance schedule ................................................................ 21 Chapter 2: Managing Your Oracle Database Introduction ................................................................................................. 24 Additional information .......................................................................... 24 Overview of Oracle architecture ................................................................. 26 Structure of the database ....................................................................... 26 Structure of the database instance ......................................................... 28 Managing components of an Oracle database ............................................. 31 Managing parameter files ..................................................................... 31 Managing control files .......................................................................... 32 Managing a database with multiple schemas ........................................ 33 Maintaining schemas ............................................................................ 34 Maintaining the database ...................................................................... 35 Starting a database ................................................................................ 36 Shutting down a database ...................................................................... 37 Managing tablespaces and datafiles ...................................................... 38
Contents
Managing redo log files ...............................................................................43 Creating online redo log files and log groups .......................................43 Viewing information about online redo log files ..................................44 Archived redo logs and ARCHIVELOG mode .....................................46 Backup procedures .......................................................................................48 Performing physical backups ................................................................48 Performing logical backups ...................................................................51 Performing partial backups ....................................................................55 If you run out of redo log space .............................................................55 If you lose a redo log group ...................................................................55 If you run out of archive log space ........................................................56 Recovering and restoring damaged databases .............................................58 Instance recovery ...................................................................................58 When instance recovery is not enough ..................................................59 Recovering datafiles or tablespaces .......................................................60 Recovering the entire database ..............................................................60 Determining which files to recover .......................................................61 Applying redo logs ................................................................................61 Determining which recovery strategy to use .........................................62 Improving recovery performance ..........................................................67 Integrity checking ........................................................................................69 Enabling redo log block checking .........................................................69 Updating ROWID values ......................................................................69 Verifying access to files ........................................................................70 Performance tuning ......................................................................................71 Checking the ALERT file ......................................................................71 Correcting LGWR delays ......................................................................71 If sessions are waiting for other sessions ..............................................72 Using DBReport ....................................................................................72 Rebuilding indexes ................................................................................74 Rebuilding tables ...................................................................................75 Coalescing free extents ..........................................................................76 Updating statistics .................................................................................77 Recompiling stored procedures .............................................................77
Contents
Chapter 3: Managing Your SQL 2005 and 2008 Server Database Introduction ................................................................................................. 80 Using SQL Server Management Studio for database management ...... 81 Using SQL statements for database management ................................. 84 Managing components of a SQL Server database ....................................... 86 Managing databases .............................................................................. 86 Managing transaction logs .................................................................... 89 Managing filegroups ............................................................................. 89 Managing backups ................................................................................ 90 Backup procedures ...................................................................................... 93 Performing full backups ........................................................................ 93 Performing incremental backups .......................................................... 95 What happens during backup ................................................................ 98 Backing up a full transaction log .......................................................... 99 Making online (hot) and offline (warm) backups .......................... 99 Restoring damaged databases .................................................................... 101 Before you start ................................................................................... 101 Automatic recovery ............................................................................. 101 Restoring a complete database backup ............................................... 102 Restoring when the database must be re-created ................................ 103 Restoring a corrupt database ............................................................... 104 Recovering the master database .......................................................... 104 Integrity checking with DBCC .................................................................. 105 Using Checkdb .................................................................................... 105 Performance tuning ................................................................................... 106 Understanding the DBReport utility ................................................... 106 Updating database statistics ................................................................ 107 Rebuilding indexes .................................................................................... 109 Dropping and re-creating indexes and other dependent objects ......... 109 Performing automatic backups .................................................................. 111 Scheduling maintenance through SQL Server Management Studio ... 111 Running maintenance utilities from DOS batch files ......................... 112 Read committed snapshot isolation (RSCI) ........................................ 113 Index
Chapter 1
Introduction
Important:The information in this guide is correct as of this release. Always refer to the product documentation from your database vendor and the vendors web site for the latest updates and information to your version of their products. The suite application database needs periodic maintenance and tuning. Without such maintenance, database operations can become considerably slower over time. This guide discusses the maintenance operations that you can perform to keep your database in optimal condition. While some product-specific information is provided for the three database management system (DBMS) products discussed in this guide, you should rely on your DBMS products documentation for non-suite issues. This guide does not take the place of training in database administration. It is strongly recommended that each person responsible for upgrading or maintaining the database at your company take a course in database administration and consult other reference materials before attempting to perform the operations described in this guide. It is also strongly recommended 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 database. This chapter contains the following sections: About the database on page 11 DBA goals in the suite environment on page 12 Utilities and scripts on page 14 Reviewing table storage on page 15 Backup and recovery on page 17
Chapter 1
Introduction
Building a maintenance schedule on page 21
10
About the database
About the database

This guide explains the database administrators responsibilities and the tasks that you must perform to keep your database in good working order. Tasks include: Managing your database server and components of your database Backup and restore strategy and procedures Performance tuning
The suite application uses a three-tier structure to deliver functionality to the desktop. The client uses a Web browser to access the applications. Application functions are presented as HTML pages or as Java applets. The application server tier consists of one or more application servers. The third tier is the database server, containing the database with all of the suite application data. Whereas a system can have several application servers, there is only one database server for a database.
The database server holds the relational database used by all your 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. This guide describes only tasks and procedures that you perform on the database server. It does not provide information about configuring the network or performing system administration tasks specific to any of the suite applications.
11
Chapter 1
Introduction
DBA goals in the suite environment

The database administrators (DBA) job is to make sure the database is running optimally whenever it is needed. This means that the database must be: Properly designed, so that its indexes reference frequently used columns, its segmentation and partitions work efficiently, and so forth Installed and configured so that it is accessible over the network Available when users need it Tuned for optimal performance, allowing users to receive the data that they request in a reasonable period of time Accurate, with no database corruption or system errors Returned to normal as quickly as possible after a failure
Whereas database design is usually part of the DBAs job, the suite database design is established before you receive the product. The design includes the segmentation, indexing, and stored procedures. Its tables have already been analyzed for performance. Do not add any indexes to the database unless specifically requested to do so by company personnel. The following sections describe the tasks that you must perform to maintain your database. Note: The terminology may be different for the different DBMSs discussed in this guide.
12
DBA goals in the suite environment
When you installed your database, a number of performance factors were considered. Many of these factors change over time and require reevaluation on a regular basis. You must perform regular maintenance to keep the database running optimally. Your maintenance schedule should include updating database statistics, recompiling stored procedures, rebuilding and reclustering tables and indexes, and identifying and correcting excessive fragmentation. Your maintenance strategy will vary depending on your companys business needs, as well as on the hardware and software resources available to you. Caution: It is strongly recommended that you back up your database before performing any maintenance.
13
Chapter 1
Introduction
Utilities and scripts

The suite application includes a number of database utilities and scripts to help you maintain your database. It is recommended that you run them on a regular basis. These utilities are: DB Manager enables you to upgrade your database. You can use the Reconcile facility in DB Manager to verify your suite application objects. Run Reconcile regularly. If a Reconcile report identifies a problem, correct it immediately. DBReport displays current information about the tables and indexes in the database. Some information in the report can vary, depending on your DBMSs, but information about fragmented objects is shown for all DBMS. Among other considerations, watch for indications of index or table fragmentation. Dropddl allows you to drop database objects, such as indexes, so you can: Avoid referential integrity errors while rebuilding or reclustering indexes Improve the performance of long-running operations
Createddl allows you to re-create database objects. After you have completed the tasks for which you dropped database objects, run the re-create script to return the dropped objects to their former state. The Stats utility runs your databases command for updating the statistical information that the optimizer uses to determine the best and most efficient access path for a database query. The optimizer uses this data to determine the best access path for data operations. Run this utility often, and especially after any large database operation such as an import or archive. But avoid running it during peak usage periods. The Recomp utility recompiles all of the stored procedures on Oracle databases. Although automatic recompilation covers most cases when stored procedures become invalid or must be updated, automatic recompilation could cause unexpected performance delays. Therefore, the database administrator should periodically check for error messages from the database that are reporting invalid stored procedures; then, if those messages are reported, recompile the stored procedures. See Recompiling stored procedures on page 77.
14
Reviewing table storage
Reviewing table storage

After the installation of a new database, the tables only contain gold data. As they are populated, check your performance statistics regularly to determine whether any of them require your attention. You should run Stats and Recomp frequently during ramp-up, because even a small number of rows added to some tables can impact the database optimizer and affect performance. Several tables in the database can grow quickly, depending on the number of employees and users who are maintained in your system, your configuration rules, and usage patterns. You should closely monitor all tables in the database and modify the storage parameters as necessary. Pay particular attention to the following tables. Specific conditions are identified, where appropriate. If you are using multiple schemas in an Oracle database, monitor these tables for each schema.
Table ACCRUALEDIT ACCRUALTRAN CARRYFORWARD HOMEACCTHIST LLELABACCTSTMM MYWTKEMPLOYEE PAYCATDDZONEMM PAYCATDISDICTMM PROJECTEDTOTAL Monitor this table if your Pay Rules are configured so that they provide actual against scheduled and actual against projected information for employees who are assigned to those Pay Rules. Monitor this table if users regularly attach comments to punches. Condition
PUNCHCOMMENTMM PUNCHEVENT
15
Chapter 1
Introduction
Table PUNCHEVENTTRC SCHEDULEDTOTAL
Condition
Monitor this table if your Pay Rules are configured so that they provide actual against scheduled and actual against projected information for employees who are assigned to those Pay Rules. Monitor this table if the Mark Posted function is used. Otherwise, it will remain empty. Monitor this table if jobs are submitted frequently through the basic scheduler/wfs.
SHFASGNMKPSTMM SHFASGNWSHFMM SHFTSEGORGTRAN SHIFT SHIFTAPPLYDATE SHIFTASSIGNMNT TIMESHEETITEM TIMESHTITMTRC WFCAUDIT WFCEXCEPTION WFCTOTAL WORKEDSHIFT
Performance of Import jobs

Database tuning is not the only factor that can affect the performance of your application. For example, if you are importing data from an external system, the following factors can affect performance: An XML Import will perform considerably faster than a Table Import. A batch job submitted for the user named Import will outperform the same job submitted for another user.
For information about performance improvements for import jobs, see the Import Users Guide.
16
Backup and recovery
Backup and recovery

Disaster recovery procedures include two phases: Regularly backing up the database so that 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. 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 implies restore. You cannot restore your database to its original condition if you did not back it up first.
Reasons to perform backups

You back up your database because many events can damage a production database: Disk drives and other system components can fail and need to be replaced. The entire system, including the disk drives, can be stolen. Viruses can damage the database, disk, or system. Physical disasters, such as an earthquake, burst pipes, or air conditioning failure during a heat wave, can damage your facility and equipment. The database can sustain accidental or malicious damage, such as when an authorized user inadvertently deletes a table or a disgruntled employee deliberately does the same thing. Bugs in the system, disk, database, or application software can corrupt the data or database structure. A software, hardware, or network upgrade can fail, requiring you to restore the old system to its original condition.
17
Chapter 1
Introduction
You might need to move the database to a new system, or move the entire computer system to a new location. You might need to restore a different copy of your database or database instance.
Some 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.
Reasons you may be unable to back up your database

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 that purpose. Nightly disk backups are not generally adequate for backing up relational database files for several reasons: Most backup programs skip open files. If the database is being used, it will not be backed up. 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. If linked files are backed up at different times while operations are in progress, the links can be out of sync.
Restoring a different copy of the database

If you take your database offline for the purpose of restoring a different copy into the same database or database instance, then you should also shut down all of the application servers that access the database.
18
Backup and recovery
Otherwise, some of the processes that are running can experience lag time when the database or instance is restored, and data may not be completely refreshed. Data may appear to be incorrect.
Types of backup
Databases provide two main types of backup: 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. Incremental backup copies the portion of the database that has changed since the last backup.
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: The frequency with which you need to do backups. Consider factors such as: The amount of data that you can afford to manually reconstruct The level of activity on 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 that you need to re-create the database. The length of time that it takes to perform a full backup of your database. Whether the length of time it takes to completely restore the database is acceptable, and, if unacceptable, how you can shorten the restoration time.
19
Chapter 1
Introduction
Whether you can perform cold backups; that is, shut down the database completely for backups, or whether you need to perform hot or warm backups to keep the database available. Whether you can take advantage of time periods of low database usage. Some examples of low usage times are the last week of the year, holiday weekends, or, in academic environments, the summer. Most databases and operating systems provide performance monitoring tools that help you analyze system usage and database demand to identify low-use times. The medium that you use and how you intend to back up the backups. Whether you need new hardware, more air conditioning, or power outlets. How you intend to test backup recovery. How you intend to verify that the data that you are backing up is good. Number of incremental backups that you want to accumulate before the next full backup, and whether you want to back up transaction logs. If your database is small, it can be more efficient to perform full backups each time, and eliminate incremental backups completely. If yours is a high availability system that cannot afford any data loss, you might perform an incremental backup every few minutes. Number of backups that 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 that you have the backup you need. 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.
20
Building a maintenance schedule
Building a maintenance schedule

Building one or more maintenance schedules will help to keep your 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 times, as discussed in Backup and recovery strategy on page 19. 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. 4. Make sure that the backup files themselves are backed up. 5. Test your recovery plan. If possible, simulate a disaster such as an air conditioning failure during a heat wave to make sure that your emergency procedures function as planned. At the very least, rebuild the database from scratch using your backups and make sure that your 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 can begin to add extra tasks: 1. Recalculate database statistics. Database statistics provide the database with information it needs to efficiently access data. If you regularly update those statistics, your database will perform better. If you are using an Oracle database, these operations must be performed while the database is running. If you are using SQL Server, you will experience better performance if your 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 on
21
Chapter 1
Introduction
page 74) while SQL Server databases might need reclustering (see Rebuilding indexes on page 36). 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: Schedule index maintenance for periods of reduced load. 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, Managing Your Oracle Database for Oracle databases, or Chapter 1, Managing Your SQL 2005 and 2008 Server Database 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.
22
Chapter 2
Managing Your Oracle Database
This chapter describes how to maintain, back up, and restore your databases on an Oracle 10g relational Database Management System (DBMS). Important:The information in this guide is correct as of this release. Always refer to the product documentation from your database vendor and the vendors web site for the latest updates and information about your version of their products. This chapter contains the following sections: Introduction on page 24 Overview of Oracle architecture on page 26 Managing components of an Oracle database on page 31 Managing redo log files on page 43 Backup procedures on page 48 Recovering and restoring damaged databases on page 58 Integrity checking on page 69 Performance tuning on page 71
Chapter 2
Introduction
This chapter explains basic techniques for creating, maintaining, and backing up databases that use Oracle as their DBMS. The product supports Oracle running on a wide variety of platforms. The guide to planning an installation lists these platforms. At the database management level, differences in platforms affect the way that you perform many tasks: Operating system commands can be different. File specifications and default locations can change. The names of Oracle utilities can differ. 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 Structured Query Language (SQL) statement syntax, cover all options, or describe every task that you might need to perform. You should rely on your operating systems documentation, specific Oracle operating system documentation, or third-party references. This chapter uses SQL statements to illustrate common maintenance operations. Other utilities, such as the Oracle Instance Manager, are explained as appropriate. If you want to use the Oracle Enterprise Manager or other utilities, see Oracles 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.
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: Oracle online manuals: Concepts, Administrators Guide, Backup & Recovery, Tuning
24
Introduction
References to Oracle online documentation refer to the Oracle 10g documentation set. These books are available at http://otn.oracle.com/ documentation/content.html.
25
Chapter 2
Overview of Oracle architecture

Oracle distinguishes between the physical files that hold the data, and the server processes and resources that are required to access and manage the data. The database instance and the database are created and managed separately. The following sections explain each aspect in more detail. A database is a collection of data. A database has logical and physical structures. Because the logical and physical structures are separate, the physical storage of data can be managed without affecting access to the logical structure. When a database is started, Oracle allocates a memory area called the System Global Area (SGA) and starts one or more Oracle processes. This enables users to access the database, and is referred to as a database instance.
Structure of the database

An Oracle database includes both a physical storage structure and a logical storage structure: The physical storage structure is made up of the actual files in which the database is stored. This structure always includes the following types of files: One or more control files, which specify information about the database, including the physical location and characteristics of the other files. When the database is started, Oracle reads the control files to identify the files that must be opened, and the memory structures that must be allocated. A parameter file specifies the characteristics of the database and the database instance. One or more datafiles are explicitly created for each tablespace to physically store the data for all logical structures in that tablespace. Temporary datafiles, which are similar to datafiles, for holding temporary data, such as data that is held during a large sort operation. One or more rollback segments or undo tablespaces record uncommitted transactions.
26
Two or more online redo log files record changes that are committed to the database. Two online redo log files make it possible to archive one while the system is writing transactions to the other. The redo log files collectively are called the redo log. Redo logs are used to reconstruct all changes made to the database.
The logical storage structure interprets the physical structure. Each database has a data dictionary, which consists of a set of tables and views that provide metadata about the logical and physical structures of the database. It includes users, integrity constraints, and space allocations and usage for schema objects. If your database instance contains multiple schemas, information about each schema and related objects are recorded in the data dictionary. See Managing a database with multiple schemas on page 33 for more information.
All Oracle databases have the same logical structure, no matter what the underlying operating system is: 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 contains one or more datafiles for storing schema objects. A datafile is a physical file on the disk. It can belong to only one tablespace and cannot be moved to another. A tablespace 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 bigfile tablespace (introduced in Oracle 10g) incorporates the concept of bigfile tablespaces. These datafiles can grow up to 32 terabytes, but can only contain one datafile per tablespace 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.
Each segment allocates extents as needed to store the segments data. This allows the database to grow in a controlled fashion. Extents might or might not be contiguous on the disk.
27
Chapter 2
The smallest unit of logical storage is the data block. Data blocks hold the actual rows of the table. The data blocks size is established when the database is created. If you are using Oracle 9i or later, differently sized data blocks can be specified for different tablespaces.
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 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. Oracle processes access the database on behalf of user processes. The structure of a process varies according to the operating systems 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 an application or tool code. For example, when a user logs in to SQL*Plus, Oracle creates a user process to run an instance of the SQL*Plus application. A user process normally uses its own private memory area, called the Program Global Area (PGA). This memory is not shareable. Server Processes
A server process coordinates communication between the database instance and a

user process. Server processes perform tasks such as parsing and executing the SQL statements, requesting services from background processes, and returning data to user processes. 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
28
particular database instance vary according to the operating systems features and the installed Oracle options. The Database Writer process (DBWR) reads data from the database and writes changed or inserted data to the database. The Log Writer process (LGWR) copies redo log entries from the redo log buffer in the System Global Area (see System Global Area on page 30) to the online redo log file. The System Monitor (SMON) performs instance recovery on startup, removes transactional object that are no longer needed, and coalesces contiguous free extents. SMON hibernates when not in use, waking up periodically to see if there is work for it to do. The Process Monitor (PMON) cleans up failed user processes by freeing resources, such as locks and memory, that the process was using. PMON hibernates when not in use, periodically checks to see if there is work. The Checkpoint process (CKPT) initiates database checkpoints. See your Oracle operating system documentation for more information. 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 ARCHIVELOG mode on page 46.
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 for more information.
29
Chapter 2
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.
30
Managing components of an Oracle database

Maintaining an Oracle database requires consideration of the following: Managing parameter files Managing control files Understanding how to start a database in different modes Shutting down a database Managing tablespaces and datafiles
Managing parameter files

The parameter file specifies the characteristics of the database, such as the database name to the size of the SGA. These values are referred to as configuration parameters or database parameters. Each database has its own parameter file. Refer to the Guide to Planning an Installation for a description of these parameters and their recommended settings. The convention for naming Oracle parameter files is: $ORACLE_HOME\DATABASE\initSID.ora for Oracle on all Windows platforms $ORACLE_HOME/dbs/initSID.ora for Oracle on all UNIX platforms
ORACLE_HOME is a logical name that identifies the Oracle installation directory. The SID is a character string from one to eight alphanumeric characters on Windows NT that identifies the Oracle instance that the parameter file defines. For the database, you might select WFC or KRON as the SID, making the parameter file name initWFC.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.
31
Chapter 2
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 on Windows, 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 database requires setting several parameters, as explained in the installation guide. 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
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 one database, and cannot be edited or modified except by Oracle. Information in the control files includes: The database name and timestamp of its creation The names and locations of datafiles, online redo log files, and archive areas The current log sequence number Checkpoint information
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
32
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 on page 37.
Managing a database with multiple schemas

Previously, the product required different database instances for different implementations of the database. However, if you are using version 5.0 or later, you can maintain multiple implementations in the same database instance. Each implementation, called a schema, is owned by a database user, and contains a discrete set of objects such as tables, indexes, and views. Each schema is independent from any other schema and is accessible from a distinct set of application servers. If you previously maintained separate database instances for training, testing, and production, you can now host them in three schemas in one database instance. If your enterprise maintains separate installations for different divisions, or subsidiaries, you can maintain them now in multiple schemas in one database instance. Maintaining multiple schemas in one database instance enables you to reduce the overhead of maintaining multiple databases, while providing database services for all your implementations. Each schema in an multiple schema environment contains all of the database objects necessary for a single implementation. Each schema is independent of any other schema defined in the database instance. Each schema is identified by a unique database user in an application server. This database user is identified in the System Configuration > System Settings Database tab. The schemas user Id is specified in the site.database.<database_name>.usr property. Its password is specified in the site.database.<database_name>.pwd property.
33
Chapter 2
Whereas multiple application servers can access the same schema, each application server can access just one schema. All schemas in a database can share the same tablespaces and can have objects with the same names associated with each schema. The names of all schemas are contained in the data dictionary.
Maintaining schemas
To add a new schema, you must create the database user for the schema. Oracle automatically adds the user to the data dictionary. Then add one or more application servers that are configured to use the new schemas user Id, and install version 5.0 or later, on those application servers. You may want to combine data from previously separate database instances. For example, you may want to have training, testing, and production in one database instance. To do so, create the database instance in the usual way. Then, create a new schema for each of these subjects. Create a database schema user for each of these schemas and assign the appropriate roles and privileges to it. Use the Oracle export and import utilities to copy the data from each separate database instance to the appropriate schema in the multiple-schema database. The versions for the objects in each schema will match the versions of the databases from which the objects were imported. You may want to create a new schema without existing data. For example, you may want to add a new instance for a division. To do so, create a database user for the new schema and assign the appropriate roles and privileges. Then run DB Manager to create an empty set of objects for that schema. You must grant the appropriate database roles and privileges to the schema user after a new schema is created. To remove a schema, drop the schema and all of its objects. This will remove the schema from the data dictionary. The associated application servers will no longer have access to the database. Use Oracle facilities to change a schemas password. The modify the password property on the application server so that the application continues to have access to the schema.
34
Maintaining the database

All of the maintenance tasks that are done at the instance level apply to all schemas. These include physical components such as control files, the parameter file, datafiles, rollback segments, and redo log files, as well as logical components such as the data dictionary, tablespaces, and segments. Log on as a user with DBA privileges, such as SYS or SYSTEM for these tasks. All of the maintenance tasks that are done for business objects are done for each schema individually. You must run the following utilities for each schema. Log on as the schema user to run these utilities for a specific schema. DB Manager DB Report Dropddl Createddl Stats Recomp
35
Chapter 2
Starting a database
Oracle lets you start a database in any of three different modes: The database can be opened for normal use. Oracle makes the database available for normal operation. The instance can be started without opening the database. Oracle starts the database instance by reading the parameter file (see Managing parameter files on page 31) 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 SGA and start the background processes. You start the instance without opening the database when you are creating the database and for certain administrative procedures. 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 DBA can perform such actions as rebuilding indexes, importing or exporting database objects, and loading large amounts of data through SQL*Loader. A user who does not have DBA rights in the database receives an error message when trying to connect. 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 command to start a database: STARTUP [PFILE = file] [OPEN] [dbname] 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. Be sure you are connected as SYS AS SYSDBA. Then use SQL*Plus for all startups and shutdowns. For Oracle on Windows platforms, you can start the
36
database from the Oracle 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 SQL*Plus command. USRPWD specifies the password for the users account. STARTTYPE requests that Oracle start either the services, the instance, or both. Oracle 9i introducted a binary parameter file called the spfile. There is syntoaz for starting the database using the -SPFILE parameter. Refer to the Oracle documentation for details. On a Windows platform, the instance does not start unless Windows services that support the database are started. Starting a database in restricted mode Use the following SQL*Plus command to start a database without opening it: STARTUP [PFILE=file] MOUNT [dbname] 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 SQL*Plus 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
37
Chapter 2
while the database is shutting down receive a message informing them that a shutdown is in progress, and connection is not permitted. The SQL*Plus 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 on page 58).
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. Disconnect all client sessions 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 one or more physical files called datafiles. Datafiles are identified by the file specification conventions of your operating system. The Guide to Planning an Installation explains how to distribute the tablespaces across disks. The following sections discuss the process for creating tablespaces. For more information, see the Guide to Planning an Installation. Creating the rollback tablespace You can choose to use rollback segments or undo tablespaces.
38
To create a rollback tablespace for the database, follow these steps: 1. Create the rollback tablespace that the 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 tablespaces 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. Use the following SQL statements to create the rollback segment and make it ready for use: ALTER ROLLBACK SEGMENT r01 ONLINE; Give the rollback segments any name that makes sense in your environment. Your databases 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.
39
Chapter 2
3. After you create the rollback segments, place the rollback tablespace online: ALTER TABLESPACE rbs1 ONLINE; 4. 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 undo tablespaces You may find that undo tablespaces are preferable to the rollback segments. Like rollback segments, undo tablespaces are used to rollback uncommitted transactions. Unlike rollback segments, they are managed at a less granular level, making them easier to manage. An undo tablespace is one that is created exclusively for managing undo information. It cannot contain tables, indexes, or any other objects. When the first Data Manipulation Language (DML) such as an insert, update, or delete statement occurs in an Oracle transaction, the transaction is bound to an undo segment in the current undo tablespace. You are likely to have one undo tablespace created when your system is installed. If you need to create an additional undo tablespace, use the CREATE UNDO TABLESPACE statement. Creating data tablespaces DBManager now gives the user the opportunity to chose user-defined tablespaces for the objects. The data tablespaces named tkcs1, tkcs2, tkcs3, tkcs4, tkcs5, tkcs6, and tkcs7, tkcs8, and tkcs9 are default tablespaces as well as a rollback or undo tablespace, and a temporary tablespace for Oracle. Other applications require additional tablespaces, as explained in the Guide to Planning an Installation. To make sure the undo tablespace is used, add the following to your inst.ora file: undo_tablespace = undotablespacename
40
If you need to create any other data tablespaces, you can use the following command. CREATE TABLESPACE TKCSn DATAFILE datafilespec SIZE 1024M DEFAULT STORAGE (INITIAL 400K NEXT 400K MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 0); The n in TKCSn represents the number of the tablespace that you are creating. there are other options to create tablespaces with specific characteristics, including AUTOEXTEND (lets a datafile expand with data volume), NEXT (size of space chunks that are added as the tablespace grows), and EXTENT MANAGEMENT (defines how the tablespaces are managed by the database). Refer to the vendor documentation for examples and other options. 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 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. In Oracle 9i, the database can be created with a default temporary tablespace.
41
Chapter 2
Adding datafiles to a tablespace The tablespaces 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. Note that this cannot be done with a bigfile tablespace. See the Oracle documentation for the syntax. 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 tables contain too many cross-table dependencies to make this a useful thing to do, but you might find some circumstances when it makes sense.
42
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.
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 your Oracle documentation. Adding a log group to an existing database Use the following command using the SQL*Plus utility to add a log 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.
43
Chapter 2
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 from the SQL*Plus: 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 may be necessary 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. Be sure you are connected as SYS AS SYSDBA and use SQL*Plus. 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 Administrators 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. 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:
44
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 that Oracle cannot access the log file, perhaps because the disk is offline or the file is damaged. Common practice for the database Create at least three redo log files. The size depends on your databases size and activity; check the alert.ora file to monitor log switches to determine whether you need to make your log files bigger. Oracles 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. It should also minimize wasted space. For example, if the log file fills 35% of a disk, you can place only two archive logs on the disk, with 30% of the disk wasted. It is usually best to make each log file slightly smaller, so that three archive logs can fit
45
Chapter 2
on the disk. You could also make the log files larger, so two archived logs fill the disk. Database creation 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 databases future growth. MAXLOGMEMBERS specifies how many members a log group can have. This parameter also does not change. Its default value depends on your operating system. 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 ARCHIVELOG mode

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. To have full backup and recovery capabilities available, your database should enable archiving.
46
Enabling archiving Enabling archiving is also called running in ARCHIVELOG mode. Use the following command to enable archiving: ALTER DATABASE mydb ARCHIVELOG; 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: 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. Manually, by entering the SQL command ALTER SYSTEM ARCHIVE LOG log-group TO destination.
If you archive manually, online redo logs are not reused until you issue the archive command; if the database runs out of online redo log space, it hangs. The best practice is to archive 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.
47
Chapter 2
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 data dictionary, the data, or both.
The physical backup must include all the files that 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, especially the Oracle Backup and Recovery manual, before you decide on your backup strategy. See Recovering and restoring damaged databases on page 58 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.
48
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 of 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 Oracle documentation. 3. Restart the database for normal operation. 4. Back up all of the following files: The control files. While the database is shut down, you can use operating system commands. All parameter files associated with the database (init.ora, config.ora). All datafiles. 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.) The password file, if your site uses it. All archived redo log files, if you are running in ARCHIVELOGMODE. In ARCHIVELOG mode, 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 database. The archived redo logs can be applied to make the database fully consistent.
49
Chapter 2
Making online (hot) backups If your database runs in ARCHIVELOG mode, 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: 1. Put the tablespace in backup mode using this SQL command: ALTER TABLESPACE BEGIN BACKUP 2. Physically back up the tablespaces 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: Whenever you make a whole database backup 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: 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 whole 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.
50
Backup procedures
Making portable backups It may be advisable to create portable backups for off-site storage. If the service representative requires a copy of your database for problem resolution or troubleshooting, you will need to provide a portable backup copy. Use the same parameters that are used for making backups with the export facility. See Specifying export characteristics on page 52 for an explanation of the parameters to use.
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. See Running the Export utility on page 54. The Export utility copies both data and data definitions to an operating system file in binary format: If you have Oracle Net, you can write this file to a device on another system on the network. You can use FTP or other file copy protocols to copy the export file across systems. You can copy the export file to tape for storage. 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: Specific tables All objects belonging to a specified users schema The full database
51
Chapter 2
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 all the commands needed to re-create the exported objects in binary format. If you are exporting the full database, you have three options for how much of the database to export: 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. Cumulative copies only those tables that changed since the last cumulative or complete export. It copies table definitions and all data, not just the changed data. For example, if only one row has been modified, the entire table is exported. 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. Beginning with Oracle10g, Oracle provides the datapump utility, which allows additional functionality and benefits for backing up and restoring databases. In the case where a customer database in encrypted, the datapump utility would need to be used for providing us a backup of their database. Refer to the Oracle documentation for details. 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.
52
Backup procedures
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 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. If you wanted to export selected schemas in a multi-schema environment, do not use FULL=Y and 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 tells Oracle to 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. 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.
53
Chapter 2
All users with CREATE SESSION rights can export their own tables. To export objects contained in another users 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. Running the Export utility To run the Export utility: 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: exp username/password PARFILE=tkcsfull.par To access online Help, enter: exp help=Y 3. To export the entire schema, export with the option USER = <database_owner>. 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 manual for details.
54
Backup procedures
Performing partial backups

If one portion of your database is more active than the rest, you can perform more frequent backups of heavily used tablespaces. In the event of a failure that requires restoration or recovery, you will then have a more recent copy of the more active tablespace and fewer changes will need to be applied from the redo logs or undo tablespace, making recovery faster.
If you run out of redo log space

If your database has 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: Add more redo log groups to give LGWR more buffers to work with. Create additional slave processes for the ARCH process to make archiving go faster. If you are archiving directly to a slow tape device such as a slow tape drive, consider archiving to a disk area and then copying the online redo logs to tape from the archive area. 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, none of the log file entries after the failed log can be used. 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.
55
Chapter 2
If you run out of archive log space

If the archive log space fills up, the ARCH process will not have room to copy the next online redo log file and will be unable 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; The OSDBA or OSOPER role must be 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: Change the destination for automatic archiving, using 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. 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;
56
Backup procedures
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: Archive to a larger disk. Make sure the ARCH process is the only process writing to the archive disk. Copy older archived redo logs to tape or other secondary storage, then delete them from the archive area. Perform full or incremental backups more often, reducing the number of archived redo logs you need to keep.
57
Chapter 2
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, rollback segments, or undo tablespaces, are used to bring the database back to a consistent state. The following section describes recovery of the database and its components. However, if you are using Oracle 8, you can use the Recovery Manager (RMAN). RMAN automates and simplifies many of the recovery operations in addition to other benefits. Refer to the Oracle documentation for details.
Instance recovery
Instance recovery restores a database to the transaction-consistent state it was in just before the 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 disk only when necessary. When it does need to write to disk, it selects 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 logs, rollback information, or undo tablespaces, to return the proper information to a user query. However, if the instance fails, the database is left in an inconsistent state:
58
Some data blocks that were 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. Some modified data blocks that were later rolled back can have been written to the disk. These modifications must be removed from the database. Applies all changes recorded in the redo logs since the last incremental checkpoint (rolls forward). Every change to data, index, rollback segments, or undo tablespaces are reapplied and the rollback segments are re-created. Opens the database for general use as soon as the cache recovery is complete. Any data that is not locked by unrecovered transactions is available. Marks all transactions that were active at the time of the failure as DEAD. This means that if a new transaction needs a resource that was locked by the dead transaction, the new transaction can immediately use the resource without waiting until SMON finishes removing the old transaction. Marks the rollback segments containing the dead transactions as partly available. SMON recovers the dead transactions, using the information in the rollback segments or undo tablespaces to remove the uncommitted data (roll back).
To bring the database back to a consistent state, Oracle does the following:
When instance recovery is not enough

You generally must restore files that were 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 recreating 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 whole 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.
59
Chapter 2
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. Use the commands appropriate to your operating system to copy or otherwise restore the files to their proper locations. If you use a third-party utility to make 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 so 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 recovery. 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.
60
Determining which files to recover

The data dictionary view V$RECOVER_FILE lists all files that need to be recovered and the problems that caused 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 in order 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; This command 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 parameters. To accept the suggested file name, use the following statement: ALTER DATABASE RECOVER CONTINUE DEFAULT; If you want the archived log files to be read from a location other than the one that is currently specified by LOG_ARCHIVE_DEST, use the following command: ALTER DATABASE RECOVER AUTOMATIC FROM alt-location; 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 for each log file in the sequence, using an ALTER DATABASE RECOVER LOGFILE statement: ALTER DATABASE RECOVER LOGFILE filename.arc;
61
Chapter 2
Determining which recovery strategy to use

The kind of restoration and recovery that you need to perform depends on what happened to your database and what files were damaged. The following strategies 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 that comprise the database are still intact after a 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 on page 58. Temporary loss of one or more files Events such as disk maintenance or repair can cause one or more database files to be unavailable temporarily. Your strategy depends on which file is unavailable. The current control fileOracle 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. Datafile in SYSTEM tablespaceOracle shuts down the database, because the information in the SYSTEM tables is necessary for ordinary operation. Correct the problem and restart the database.
62
Datafile in user tablespaceFor read operations, Oracle returns an error, but the database continues to run. When a write operation fails, including the checkpoint write to the file header, Oracle returns an error in the DBWR trace file and takes the datafile offline.
If 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. Redo log fileIf 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. Archive areaSpecify an alternate location for archiving. Do one of the following: Stop automatic archiving and archive manually until the archive area is available. Stop automatic archiving, then restart, specifying a secondary location: SQL> ARCHIVE LOG STOP SQL> ARCHIVE LOG START alt-location Rollback segmentThe 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.
63
Chapter 2
Permanent loss of a datafile When the damaged or missing files are not part of the SYSTEM, rollback or undo tablespaces, 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 commands to notify Oracle of the new location: ALTER TABLESPACE ts1 RENAME DATAFILE old-name TO new-name; You can rename more than one file with the same command provided they are in the same tablespace. To do so, separate file names by commas. 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 on page 43. 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.
64
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 commands to notify Oracle of the new location: ALTER TABLESPACE ts1 RENAME DATAFILE old-name TO new-name; You can rename more than one file with the same command provided they are in the same tablespace. To do this, separate file names with commas. 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.
65
Chapter 2
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 nevertheless 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. 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. If you are recovering to another point in time, you need the control file that corresponds to the database at that point.
2. Apply archived redo log files.
66
Improving recovery performance

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: 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. Limit the number of modified buffers. Instance recovery performance is roughly proportional to the number of modified buffers that were not written to the database at the time of the crash or other event that caused recovery to be needed. Oracle automatically maintains a pointer to the oldest modified 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. Operations other than full checkpoint cause data blocks to be written to disk, so the incremental checkpoints are usually more recent than the full checkpoints. The DB_BLOCK_MAX_DIRTY_TARGET parameter limits the number of modified buffers that can be in memory at any one time. A smaller value for this parameter forces the buffers to be written more often. This results in longer processing time while the database is running, but instance recovery takes less time. If you have to be able to recover your database very quickly, or if you use very large buffer caches, experiment with changing this setting. Note: Whereas limiting the number of modified buffers can improve the performance of any necessary recoveries, it can degrade the performance of your application. You must consider all factors carefully before changing this setting.
67
Chapter 2
Recover only what needs to be recovered. Consider offline recovery. Recovery while the database is open runs in parallel with normal operations and completes 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: A database into which you can import 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, using the Oracle EXP and IMP utilities Oracle Export files cannot be read by earlier versions of the Import utility.
68
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 available for recovery if the database fails. To make the corrupt log group available for logging again, run the following command from the SQL*Plus: 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;
69
Chapter 2
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 SQL*Plus: 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.
70
Performance tuning
Performance 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 that you might need to perform. This section provides an overview of performance tuning. There are a number of excellent books you might use for more in-depth information.
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: $ORACLE_HOME\ADMIN\SID\BDUMP for Oracle on Windows NT $ORACLE_HOME/rdbms/log for Oracle on UNIX systems
Correcting LGWR delays

If LGWR has to wait for a log group to become available, either because a checkpoint has not completed or because ARCH is still writing the next log to the archive, you can investigate the following solutions: Add more log groups. Move the archive to a faster disk. Make the log files bigger. If you are archiving directly to tape, consider archiving to disk and copying to tape from the disk directory.
71
Chapter 2
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.
Using DBReport
DBReport is a utility that is provided by Kronos. You can find it in C:\Kronos\WFC\applications\scripts\database\ ora\dbautilities. It shows current information about the tables and indexes that are in the database. Follow these steps to run it: 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 SQL*Plus default directory. To specify an alternate location for this file, modify the script so that it specifies the drive letter and complete directory name for the location that you want. The following tables describe the contents of these reports:
72
Performance tuning
Database Table report

Column TABLE NAME # ROWS BLOCKS TOTAL # BYTES NEXT EXTENT (BYTES) # OF EXTENTS Description Name of the table Number of rows in the table Number of blocks allocated for the table Total number of bytes that are allocated for the table Number of bytes that are allocated for the next disk extent 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 are split across multiple blocks because they are too large to fit into one block. EMPTY BLOCKS BELOW HWM TABLESPACE Proportion of completely empty blocks below the high-water mark Tablespace in which the table resides
Database Index report

Column INDEX NAME TABLE NAME DISTINCT KEYS BLEVEL TOTAL # BYTES NEXT EXTENT (BYTES) # OF EXTENTS Description Name of the index Table to which the index applies Number of distinct entries in the index Number of levels within the index structure Total number of bytes that are allocated for the index Number of bytes that are allocated for the next disk extent Number of extents that are allocated for the index
% MAX EXTENTS Percentage of maximum extents that have already been allocated for the index
73
Chapter 2
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 using the procedures in the next section. You can also use the the command ALTER INDEX <index_name>, which rebuilds the index but also keeps the old index itact so that current operations can use it. 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. SQL script files are provided 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 applications. The SQL scripts are located as follows: C:\Kronos\WFC\applications\scripts\database\ ora\dbautilities. Dropping dependent objects To drop all dependent objects from a set of tables, follow these steps: 1. Open the dropddl.sql file 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:
74
Performance tuning
start drop.sql Re-creating dependent objects To re-create all dependent objects for a set of tables: 1. Open the creatddl.sql file in a text editor. 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
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, 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: ANALYZE tablel hr1 list chained rows; SELECT * from chained_rows where table_name= hr1;
Refer to the Oracle Performance and Tuning Manual for more information. 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
75
Chapter 2
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. SMON periodically coalesces free extents for tablespaces that have a nonzero value for the PCTINCREASE storage parameter. However, use 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 see the amount of coalesced free space in a tablespace, use the 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. To manually coalesce the free space in a tablespace, run the ALTER TABLESPACE command: ALTER TABLESPACE <ts1> COALESCE;
76
Performance tuning
Updating statistics
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. If the optimizing statistics are outdated, the optimizer can make poor execution decisions. The optimizer determines the best and most efficient way to implement a query. Oracle offers two optimizer choices: RULE and CHOOSE. RULE is expected to become obsolete before long. Use the cost-based optimizer CHOOSE for your database. Performance tuning and benchmarking for the database are done using CHOOSE. Cost-based optimizing uses previously gathered statistics to determine whether it is more efficient to scan the table or to merge an existing index. The parameter OPTIMIZER _MODE lets you tell Oracle whether to optimize for faster response or shorter execution time: 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. 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.
Use the DBMS_STATS utility to generate database statistics. You can find
this script in the C:\Kronos\WFC\applications\scripts \database\ora\dbautilities folder. To run this utility: 1. Log on to SQL*Plus as the schema owner (for example, tkcsowner). 2. Execute the statsddl.sql script to update all statistics for objects in the Workforce Central database.
Recompiling stored procedures

The Recomp utility recompiles all of the product stored procedures. Although automatic recompilation covers most cases when stored procedures become
77
Chapter 2
invalid or must be updated, automatic recompilation could cause unexpected performance delays. Periodically, you should check for error messages from the database that report invalid stored procedures; if those messages are reported, use this utility to recompile the stored procedures. The utility is available in the C:\Kronos\WFC\applications\scripts\database\ora \dbautilities folder. To run the Recomp utility: 1. Log on to SQL*Plus. 2. Run the recmpddl.sql script to generate a file named recomp.sql in the current directory. Enter the following command: start recmpddl.sql 3. Enter the following command to run recomp.sql: start recomp.sql
78
Chapter 3
Managing Your SQL 2005 and 2008 Server Database
This chapter describes how to maintain, back up, and restore your databases on a Microsoft SQL Server 2005 and 2008 DBMS. Important:The information in this guide is correct as of this release. Always refer to the product documentation from your database vendor and the vendors web site for the latest updates and information about your version of their products. It contains the following sections: Introduction on page 80 Managing components of a SQL Server database on page 86 Backup procedures on page 93 Restoring damaged databases on page 101 Integrity checking with DBCC on page 105 Performance tuning on page 106 Rebuilding indexes on page 109 Performing automatic backups on page 111
Chapter 3
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 Management Studio 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 Management Studio 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 that you can enter in the Management Studio window. This chapter does not explain all possible options. Unless otherwise stated, you should log in to SQL Server using an account with sysadmin privileges. Other accounts have fewer rights and might not be able to perform all the necessary tasks.
80
Introduction
Additional information Many good courses and books exist. This list is a sampling of what is available: About Windows and System Administration Using Windows NT Server 4 by Roger Jennings et. al., Que Corporation Microsoft SQL Server System Administration course SQL Server Books Online Inside Microsoft SQL Server 2005: Query Tuning and Optimization by Kalen Delaney, Microsoft Press Microsoft SQL Server Database and Application Performance course SQL Server Books Online
About SQL Server and Relational Databases
About Database Administration
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 the SQL Server Management Studio graphical interface facilities to access and manage database functions. SQL Server provides a number of stored procedures. Stored procedures that are provided by SQL Server are called system stored procedures. You can also create user stored procedures.
Using SQL Server Management Studio for database management

SQL Server Management Studio is a graphical database management tool that is included with SQL Server 2005 and SQL Server 2008. You can use SQL Server Management Studio to manage your entire database environment and perform nearly all of your database maintenance tasks.
81
Chapter 3
Defining and using server groups SQL Server Management Studio 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. In the Registered Servers pane, right-click a server or a server group and then select New > Server Group. (If the Registered Servers pane is not visible, select View > Registered Servers from the Management Studio menu bar.) 2. In the New Server Group dialog box: In the Group name field, type a unique name for the server group. (Optional) In the Group description field, enter text that describes the group. In the Select a location for the new server group field, select a location for the group. Review the information that you specified and then click Save. The new server group appears in the hierarchy of the Registered Servers pane in the location that you specified.
Using SQL Server Before anyone can access databases under SQL Server, SQL Server itself must be running. SQL Server normally runs as a Windows service called MSSQLServer. You can start the server manually or you can set up SQL Server to start automatically when the system starts. You manage the server through the SQL Server Management Studio or through the Windows Services facility (Start > Control Panel > Administrative Tools > Services). Starting SQL Server To start the MSSQLServer service on the server through the Windows Service Manager, you must have Windows administrator rights on the server. To start the server from SQL Server Management Studio, right-click the name of the server in the hierarchy of the Registered Servers pane and then select Start. (If
82
Introduction
the Registered Servers pane is not visible, select View > Registered Servers from the Management Studio menu bar.) 1. In the Object Explorer pane of Management Studio, find the name of the server that you started. (If the Object Explorer pane is not visible, select View > Object Explorer from the Management Studio menu bar.) 2. In the hierarchy under the server name, right-click SQL Server Agent and then select Start. Configuring SQL Server to start automatically at start time To start SQL Server automatically when the system starts: 1. Select Start > Control Panel > Administrative Tools > Services. 2. From the list of services, select SQL Server (MSSQLSERVER). 3. From the Services menu bar, select Action > Properties. 4. On the General tab of the SQL Server (MSSQLSERVER) Properties dialog box, select Automatic in the Startup type drop-down list box. 5. If you are using any SQL Server scheduled jobs, follow the same procedure to set up the SQL Server Agent to start automatically as well: a. Select SQL Server Agent (MSSQLSERVER) from the list of services. b. From the Services menu bar, select Action > Properties. c. On the General tab of the SQL Server Agent (MSSQLSERVER) Properties dialog box, select Automatic in the Startup type drop-down list box. 6. Click OK. Stopping SQL Server You can stop SQL Server locally, from a client, or from another server. You can use SQL Server Management Studio, the Windows Services facility (Start > Control Panel > Administrative Tools > Services), or the net stop command from the servers operating system prompt. The recommended sequence for a shutdown that is not an emergency is as follows:
83
Chapter 3
1. Pause the MSSQLServer. This prevents new users from gaining access to the system, but allows current users to complete their tasks. To pause the server from Management Studio, right-click the name of the server that you want to pause and select Pause. 2. Broadcast one or more messages warning users that SQL Server is about to shut down. To do this, you can broadcast an e-mail, or use the net send/users command. To use the net send command, open a DOS window and type it. 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, right-click the name of the server that you want to stop and then select 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 the transaction log file for every database. This record counts as an alteration for the purpose of loading backup files. 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. If you need to bring the system to an immediate halt, use SHUTDOWN WITH NOWAIT to stop the system without waiting for current users to finish, or stop the service from the Windows Services panel. Note: If you are using Management Studio when you issue the SHUTDOWN WITH NOWAIT command, then the system does not write a checkpoint record.
Using SQL statements for database management

You can perform most database management operations using SQL statements or system stored procedures.
84
Introduction
To use a SQL statement: 1. Select Start > Programs > Microsoft SQL Server > SQL Server Management Studio. 2. In the Object Explorer pane of Management Studio, find the name of the server. 3. In the hierarchy under the server name, select Databases. 4. Do one of the following: To create and execute a new SQL statement, right-click on the database name and select New Query. To edit or execute an existing SQL statement, select the database name and then select File > Open from the menu bar.
5. In the SQL workspace tab, use the right-click menu options or the toolbar buttons to design and execute SQL queries to get information from the database or to perform maintenance on the database. Management Studio does not require you to register the servers that you will monitor. The Management Studio login window opens automatically. To log in, provide the login ID and password for the server that you want to manage. Management Studio allows multiple connections to the same server, under the same or different login IDs. To connect to additional servers, select File > Connect Object Explorer from the menu bar and fill out the login window for the new connection. Within Management Studio, you can execute multiple queries simultaneously by including the word go between SQL statements. This tells SQL Server to execute the current batch. 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.
85
Chapter 3
Managing components of a SQL Server database

A SQL Server database resides on one or more files. The database consists of a data portion and a log portion, which should 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: Managing databases Managing transaction logs Managing filegroups Managing backups
Managing databases
Managing databases involves: Defining and setting up the database Managing Transaction logs
The following sections describe these procedures. Adding files to filegroups To add files to filegroups in the database: 1. Select Start > Programs > Microsoft SQL Server 2005> SQL Server Management Studio. 2. In the Object Explorer pane of Management Studio, find the name of the server where you are managing the database. 3. In the hierarchy under the server name, select Databases and then right-click on a database name. 4. In the Database Properties window, select Files from the hierarchy on the left.
86
5. In the properties workspace on the right, click Add to add a blank row to the list. 6. In the Logical Name column, enter a database file name in the blank field below the default data file. For example, for the database named tkcsdb, the file name might be tkcsdb_data_tkcs7. 7. Accept the default file location in the Path column or use the Browse button in that column to change the location. 8. Enter a filegroup name in the Filegroup column. You must use tkcs1 through tkcs8. 9. Repeat steps 5 through 8 for as many database files as necessary. 10. For the other columns, accept the defaults. Optionally, you can use the Autogrowth column to control the maximum file size if there is a shortage of disk space on the server. 11. Click OK. 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. In the Object Explorer pane of Management Studio, right-click on the database name and then select Properties. 2. In the Database Properties window, select Options. 3. Click the expand symbol as necessary to expand the list of options under the categories. 4. To set or disable an option, click in the settings field (such as True or False) and use the drop-down arrow to select a setting from the list.
87
Chapter 3
5. Click OK to apply the changes. Getting information about databases The sp_helpdb system stored procedure displays information about a database and its files. For example, if you run the statement sp_helpdb sql_dev_wtk330, and you installed your database in a standard way, the following output appears: name db_size owner dbid created status compatibility_level ------------------------------------------------------------------------sql_dev_wtk330 22.56 MB tkcsowner 8 Sep 20 2002 Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=SIMPLE, Version=539, Collation=SQL_Latin1_General_CP1_CI_AS, SQLSortOrder=52, IsAutoShrink, IsAutoCreateStatistics, IsAutoUpdateStatistics name fileid filename filegroup size maxis growth usage ----------------------------------------------------------------------------------------Amsterdam 1 c:\databases\mssql\wtk_Data.MDF PRIMARY 4544 KB Unlimited 10% data Log 2 c:\databases\mssql\wtk_Log.LDF NULL 1024 KB Unlimited 10% log tkcs1 3 c:\databases\mssql\wtk_tkcs1_data.NDF tkcs1 5248 KB Unlimited 10% data tkcs2 4 c:\databases\mssql\wtk_tkcs2_data.NDF tkcs2 3840 KB Unlimited 10% data tkcs3 5 c:\databases\mssql\wtk_tkcs3_data.NDF tkcs3 3200 KB Unlimited 10% data tkcs4 6 c:\databases\mssql\wtk_tkcs4_data.NDF tkcs4 1152 KB Unlimited 10% data tkcs5 7 c:\databases\mssql\wtk_tkcs5_data.NDF tkcs5 1024 KB Unlimited 10% data tkcs6 8 c:\databases\mssql\wtk_tkcs6_data.NDF tkcs6 1024 KB Unlimited 10% data
88
tkcs7 tkcs7 tkc82 tkcs8
9 1024 10 1024
c:\databases\mssql\wtk_tkcs7_data.NDF KB Unlimited 10% data c:\databases\mssql\wtk_tkcs8_data.NDF KB Unlimited 10% data
Managing transaction logs

If you ever need to restore a database, SQL Server needs to know every change that was made to that database since the last time it was restored. It accomplishes this by recording information about every change that is made to the database. This information is written to the transaction log file. The transaction log can also be used to roll back transactions. 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. If there is not enough room for your transaction log, you receive error 1105, Can't allocate space for object '<syslog>' in database '<db name>' because the '<log segment>' 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 on page 99 for what to do in this situation. Then either perform backups more often, increase the size of the transaction log, or both.
Managing filegroups
The database uses filegroups to contain all data and functions. A SQL Server database has one filegroup by defaultPRIMARYto store the system tables as well as other database objects, unless you create additional filegroups.
89
Chapter 3
The Guide to Planning an Installation explains how to create the filegroups that the product 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. The application takes care of placing indexes, tables, and so on, in the appropriate filegroup. 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 Guide to Planning an Installation explains how to distribute logical devices when you do not have the recommended number of disks to devote to the database. File creation can fail if the SQL Server process does not have rights in the operating system to create the physical file, or if there is not enough space on the disk to create a file of the size you specify.
Managing backups
SQL Server 2005 backup device objects (backup devices) are files that store database backups. They connect the logical backup name, as the user sees it, to the physical files in which the backup is stored. You can perform full and incremental backups. Backup 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 is BACKUP DATABASE To back up a transaction log is BACKUP LOG.
In addition to defining the database devices for the database, you must define one or more backup devices for the transaction log files. 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.
90
Backup tips Keep the following in mind as you develop and implement your backup strategy: 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. If you choose the Simple Recovery Model, schedule full database backups for at least once per day. With this method, data recoverability is limited to the last full database backup. 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 on page 93 and Performing incremental backups on page 95. 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 timekeepingdb TIMEKEEPERDB_BACKUPS. To define a backup device: 1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Tasks > Back Up. 2. In the Destination area of the Back Up Database window, click the Add button. 3. 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. 4. Click OK.
91
Chapter 3
Using SQL statements Use Management Studio to access the sp_addumpdevice system stored procedure. Use this stored procedure to add a disk backup device: sp_addumpdevice 'disk', 'logical_name','physical_name'
92
Backup procedures
Backup procedures
The following sections explain how to do full and incremental backups in SQL Server Management Studio. 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: Adding, changing, or removing databases or files Adding or removing system login IDs 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 Temporary backup devices on page 100). You can optionally perform the following: If you suspect that your database is severely corrupted, you should run the Database Consistency Checker (DBCC) checkdb command to detect and fix structural integrity problems. In any case, you should run checkdb periodically. For more information, see Integrity checking with DBCC on page 105. Back up your transaction log before beginning a full backup to make the full backup go faster.
93
Chapter 3
Using the SQL Server Management Studio To perform a full backup using SQL Server Management Studio, do the following: 1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Tasks > Back Up. The Back Up Database window opens. 2. Select General from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Source area, select Full from the Backup type drop-down list box and then select the Database option in the Backup component area. b. In the Backup set area, accept the default name or enter a backup name in the name field. You can optionally add a description that includes the reason for the backup and specify an expiration date. c. In the Destination area, accept the default backup file or click the Add button and enter the full path name for the backup file that you want to use (or click the ellipsis button to browse the local system for an drive and directory). 3. Select Options from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Overwrite media area, accept the default selections to append to an existing file. However, if you do not want to append to an existing file, select the Overwrite all existing backup sets option instead. b. (Optional) Set other backup parameters, such as verification and backup expiration date. 4. Select OK to start the backup. Note: To schedule the backup to occur at a specific time, use the SQL Server Agent to create a job.
Using SQL statements The basic SQL statement to back up a database is:
94
Backup procedures
BACKUP DATABASE dbname TO backup_device [, backup_device2 [..., backup_device32]] [WITH {INIT | NOINIT}] 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 93 before you can perform an incremental backup, sometimes called a backup transaction log in SQL Server. In addition, check the following:
95
Chapter 3
Make sure that the Recovery model option is not set to Simple. Setting that option to Simple causes the transaction log to be emptied every time SQL Server performs a checkpoint operation, usually every few minutes. To view and change this setting, right-click on the database name, select Properties, and then right-click on Options. Typically, you specify Full for the Recovery model setting. The incremental backup fails if a nonlogged operation has been performed since the last backup. Perform a full backup instead.
96
Backup procedures
Using SQL Server Management Studio To perform an incremental backup using SQL Server Management Studio, do the following: 1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Tasks > Back Up. The Back Up Database window opens. 2. Select General from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Source area, select Transaction Log from the Backup type dropdown list box. b. In the Backup set area, accept the default name or enter a backup name in the name field. You can optionally add a description that includes the reason for the backup and specify an expiration date. c. In the Destination area, accept the default backup file or click the Add button and enter the full path name for the backup file that you want to use (or click the ellipsis button to browse the local system for an drive and directory). 3. Select Options from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Overwrite media area, accept the default selections to append to an existing file. However, if you do not want to append to an existing file, select the Overwrite all existing backup sets option instead. b. (Optional) Set other backup parameters, such as verification and backup expiration date. 4. Select OK to start the backup. Note: To schedule the backup to occur at a specific time, use the SQL Server Agent to create a job.
Using SQL statements The SQL statement to back up the transaction log in SQL Server 2005:
97
Chapter 3
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. 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. This option is also used before a full back up. 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 databases 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. In SQL Server 2008, BACKUP LOG options TRUNCATE_ONLY and NO_LOG are not supported. The transaction log is automatically truncated when the database is using the simple recovery model. If you must remove the log backup chain from a database, switch to the simple recovery model. refer to Microsoft Books Online for more information.
What happens during backup

When you issue a BACKUP DATABASE command either directly or through SQL Server Management Studio, SQL Server performs the following steps:
98
Backup procedures
1. Writes all completed transactions to disk 2. Performs any necessary tasks related to 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.
Making online (hot) and offline (warm) backups

A warm backup, also called a standby system, is a duplicate system that is kept in sync with the main system so that 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
99
Chapter 3
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. Temporary backup devices If necessary, you can define and create a temporary backup device. A temporary backup device enables you to back up to a different file. For example, you might want a snapshot of your database or transaction log. It 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 LOG 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.
100
Restoring damaged databases

This section describes the steps that you need to follow to return a damaged database to normal.
Before you start

You cannot load into a database that is being used. If you are attached to the database, you are using it. Make sure that no other users are attached to the database, and then connect to a different database before you start the restore. 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. 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. It rolls back uncommitted transactions. It writes to the database any committed transactions that were still in the cache. 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.
101
Chapter 3
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 Management Studio, follow these steps: 1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Tasks > Restore > Database. The Restore Database window opens. 2. Select General from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Destination for restore area, accept the defaults or select a different database and time setting. b. In the Source for restore area, accept the default source and location for the backup or specify different ones. c. In the Select backup sets to restore box, examine the dates, times, and names, and then select a full backup to restore. 3. Select Options from the hierarchy on the left side of the window. You can then specify whether to overwrite the existing database, preserve replication settings, prompt before restoring each backup, restrict access to the restored database, and more. 4. Click OK. 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 Management Studio:
102
1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Tasks > Restore > Database. The Restore Database window opens. 2. Select General from the hierarchy on the left side of the window and then do the following in the workspace that appears on the right side of the window: a. In the Destination for restore area, accept the defaults or select a different database and time setting. b. In the Source for restore area, accept the default source and location for the backup or specify different ones. c. In the Select backup sets to restore box, examine the dates, times, and names, and then select only the incremental backup sets that you want to restore. 3. Select Options from the hierarchy on the left side of the window. You can then specify whether to overwrite the existing database, preserve replication settings, prompt before restoring each backup, restrict access to the restored database, and more. 4. Click OK.
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 Management Studio. 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 Management Studio and follow these steps: 1. In the Object Explorer pane of Management Studio, right-click on the database name and then select Delete. 2. Confirm that the correct database is selected and then click Yes when prompted to delete the database. 3. Create the database as described in the Guide to Planning an Installation.
103
Chapter 3
4. Restore the database by performing a complete database backup restoration as described in Restoring a complete database backup on page 102.
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 on page 103.
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 re-created on page 103. However, the server must be in single-user mode. 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 on page 102.
104
Integrity checking with DBCC
Integrity checking with DBCC

Databases sometimes become corrupted, and corruption can be so severe that it prevents an otherwise successful backup from loading properly. Therefore, you need to periodically check your databases structural integrity. Microsoft SQL Server supplies DBCC (Database Consistency Checker) to help you detect and fix structural integrity problems. You issue DBCC commands from Management Studio or a DOS.bat file. You can use the Database Maintenance Plan Wizard in SQL Server Management Studio to create a schedule to run DBCC commands. Other DBCC commands return performance information. Those commands are explained in Performance tuning on page 106. You should run DBCC commands on both your product and master databases.
Using Checkdb
Checkdb checks each table in a database for pointer and data page errors. You should run it regularly to check for low-level corruption. The checkdb 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 nondisclosure 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.
105
Chapter 3
Performance tuning
When you receive your database, it is already preconfigured with a number of common administrative 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 database. You run DBReport from Management Studio, as follows: 1. In Management Studio, connect to the database. 2. Click the Open File button on the toolbar. Locate and select the dbreport.sql file. By default, this script is installed in \<company_name>\Scripts\Database\MSS\DBAutilities, but you can copy it to any convenient directory. Management Studio 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 <company_name> Database Report. The columns in the report provide the following information: The Table column lists the names of every table in the database. Rows tells how many rows are currently in the table. Pages tells how many pages are allocated for the table. Space tells how much space, in megabytes, is allocated for the table.
106
Performance tuning
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.
Updating database statistics

If you have disabled the automatic generation of database statistics (that is, auto update stats is set to off) to improve performance, sometimes the database statistics can become stale. To update the database statistics for all tables in the database, use kron_updatestats. By default, this utility samples tables at two rates: Standard3% of each tables rows for tables that are not considered large. Large10% of the tables rows for tables that are consider large. A table is considered large when it exceeds 5 million rows.
When you run kron_updatestats, you can change these defaults and specify the standard sample percentage, large table sample percentage, and the number of rows that identifies a large table. 1. Start Management Studio. 2. Connect to the database, using a user name and password with system administrator or database owner (dbo) privileges. 3. Issue the following command: exec installation_directory\scripts\database\mss\ dbautilities\kron_updatestats [standard_percentage,] [large_percentage,] [large_number_of_rows] where: standard_percentagethe sample rate for standard tables. large_percentagethe sample rate for large tables, as defined by the number of rows specified in large_number_of_rows.
107
Chapter 3
large_number_of_rowsthe number of rows that identifies a large table that will be sampled at large_percentage. 4. After kron_updatestats runs, check the SQL Server log for results. Examples: exec kron_updatestats uses the default settings and samples standard tables at 3%, large tables at 10%, and defines large tables at 5,000,000 rows. exec kron_updatestats null, 30 samples standard tables at 3%, large tables at 30%, and defines large tables at 5,000,000 rows. exec kron_updatestats 10 samples standard tables at 10%, large tables at 10%, and defines large tables at 5,000,000 rows. exec kron_updatestats null, 30, 1000000 samples standard tables at 3%, large tables at 30%, and defines large tables at 10,000,000 rows.
108
Rebuilding indexes
Rebuilding indexes
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 Management Studio. Because rebuilding an index involves unloading the table, sorting it, and reloading, it can take a significant amount of time and space in tempdb. You can, however, continue to use the table. 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 tables 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 tables original fill factor. WITH NOINFOMSGS suppresses display of informational messages so you can see errors more clearly.
Dropping and re-creating indexes and other dependent objects

Software for the database includes SQL script files to generate the Data Definition Language (DDL) statements to drop and re-create indexes, constraints, and other dependent objects.This script can be found in C:\Kronos\WFC\applications\scripts\database\mss\dbauti lities. To drop all objects that depend on a set of tables:
109
Chapter 3
1. In Management Studio, open the dropddl.sql file. 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 drop.sql file. 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 Management Studio, open the creatddl.sql file, found at C:\Kronos\WFC\applications\scripts\database\mss\dba utilities. 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.
110
Performing automatic backups

SQL Server provides several ways to automate your backup tasks: Use the SQL Server Management Studios Maintenance Plan Wizard 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 Management Studio

Use SQL Server Management Studios 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 Maintenance Plan Wizard, perform the following steps: 1. In the Object Explorer pane of Management Studio, click to expand the server name and then select Management. 2. Under Management, right-click on Maintenance Plans and select Maintenance Plan Wizard. 3. Click Next in the first Maintenance Plan Wizard window. 4. In the Select a Target Server window, accept the default server name and information, or use the browse button to select a different server. Change the default name and description information as necessary. Then, click Next. 5. In the Select Maintenance Tasks window, select the check boxes next to the maintenance tasks that this maintenance plan will perform. Then, click Next. 6. In the Select Maintenance Task Order window, specify the order in which the tasks should be performed. 7. In the Define Update Statistics Task window: a. Click the down arrow in the Databases field and use the drop-down dialog box to select which databases you want to set up a maintenance plan for. Then click OK.
111
Chapter 3
b. In the Update area of the window, accept the default statistics setting or select another one and then click Next. 8. In the Select Plan Properties window, define a schedule for the plan. Then, click Next. 9. In the Select Report Options window, specify how you want to save and distribute the report that contains the actions performed by the maintenance plan. Then, click Next. 10. In the Complete the Wizard window, confirm the selections that you made for the plan and then click Finish. The wizard creates the tasks and schedules them. 11. In the Maintenance Plan Wizard Progress window, click the Report button to view, save, copy, or e-mail the report, and then click Close. To monitor and change any of the tasks in the maintenance plan from SQL Server Management Studio, use the SQL Server Agent: 1. In the Object Explorer pane of Management Studio, click to expand the server name and then select SQL Server Agent > Jobs from the hierarchy. 2. Under Jobs, right-click on the name of the maintenance plan and use the menu of options.
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 Management Studio 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 used at your site in the command.
112
The file dump.in contains the following text: backup database tkcsdb to tkcsdb_dump 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.
Read committed snapshot isolation (RSCI)

Read committed snapshot isolation implements a data locking strategy. Users who need to lock access to prevent different operations from blocking each other can use this utility. For each database, use the following command: alter database <name> set read_committee_snapshot_on This utility is available beginning with SQL Server 2005. See the SQL Server Books Online for more information.
113
Index
A
ADD DATAFILE option 42 ADD LOGFILE GROUP option 43 ADD LOGFILE MEMBER option 44 adding datafiles ALTER TABLESPACE command 42 to a tablespace 42 adding log file group to existing database 43 adding redo log file to existing log group 44 advanced queuing (Oracle option) 29 ALTER DATABASE command ADD LOGFILE GROUP 43 ADD LOGFILE MEMBER 44 BACKUP 50 CLEAR UNARCHIVED LOGFILE GROUP 69 DROP LOGFILE GROUP 44 DROP LOGFILE MEMBER 44 RECOVER AUTOMATIC 60, 61 RECOVER AUTOMATIC FROM 61 RECOVER CONTINUE DEFAULT 61 RECOVER DATAFILE 60 RECOVER LOGFILE 61 RECOVER TABLESPACE 60 ALTER ROLLBACK SEGMENT command ONLINE 39 to place segment online 39 ALTER SYSTEM command 56 ARCHIVE ALL 49 ARCHIVE LOG CURRENT 56, 57 ARCHIVE LOG START 47, 57
ARCHIVE LOG STOP 56 ARCHIVE LOG TO 47 CHECK DATAFILES 70 ENABLE RESTRICTED SESSION 37 ALTER TABLESPACE command ADD DATAFILE 42 adding datafiles 42 BEGIN BACKUP 50 COALESCE 76 END BACKUP 50 OFFLINE FOR RECOVER 64 RENAME DATAFILE 64, 65 alternate archive destination 63 alternate backup strategies 67 ANALYZE TABLE statement COMPUTE STATISTICS 77 VALIDATE REF UPDATE option 69 ARCH process 43 database hangs 71 LOG_BLOCK_CHECKSUM parameter 69 running out of space 57 slave processes for 55 starting 47 ARCHIVE LOG command ALL option 63 CURRENT option 56 NEXT option 63 STOP option 63 archive log space area unavailable 63 running out of space 56
Index
archived redo logs 46 backing up 49 restoring datafiles 64 with inconsistent backups 51 ARCHIVELOGMODE 46 online backups 50 partial backups with 49 archiving changing destination 56, 63 destination 47 privileges for 56 specifying a second destination 47 starting in parameter file 47 stopping 63 archiving, automatic stopping 56 archiving, manual 47 ARCHIVE LOG ALL 63 ARCHIVE LOG NEXT 63 Auto Start Server at Boot Time option 83 automatic archiving stopping 63 automating backups 111
B
background processes 28 at database start 36 implementation 29 BACKUP DATABASE statement steps 98 using 95 with temporary backup devices 100 backup devices defining 91 for Enterprise eTIME database 90 tape 95 temporary 100 backup files definition of 90 backup strategies
for master database 93 for online redo logs 49 for Oracle databases 49 BACKUP TRANSACTION statement, with temporary backup devices 100 backups ARCHIVE ALL 49 archived redo logs 49 automating 111 cold 49 control files 49 datafiles 49 frequency 19 full 19 hot 50 inconsistent 50 incremental 12, 95 Maintenance Plan Wizard 111 master database 93 of closed database 50 of control files 50 of individual tablespaces 50 of online redo logs 49 offline (cold) 49 online (hot) 50 parameter files 49 partial 55 password files 49 preliminary procedures 93 reasons for 17 rollback tablespaces 55 scheduling 111 strategies 19 terminology 19 transaction logs 95 types 19 when to perform 93 backups, logical See Export utility batch files, for backup 111
Index
broadcasting a shutdown message 84 building maintenance schedules 21
C
changing archive destination 63 changing the MSSQLServer startup parameters 83 CHECK DATAFILES option 70 Checkdb DBCC command 105 before backup 93 checkpoint process See CKPT process checkpoints 32 on recovery 99 on shutdown 84 truncate log in SQL Server 96 checksum errors 69 CKPT process 29 COMPUTE STATISTICS option 77 config.ora files 31 configuration parameters BACKGROUND_DUMP_DEST 71 DB_BLOCK_MAX_DIRTY_TARGET values 67 in other files 31 LOG_ARCHIVE_DEST 47, 61 LOG_ARCHIVE_DUPLEX_DEST 47 LOG_ARCHIVE_FORMAT 61 LOG_ARCHIVE_START 47 LOG_BLOCK_CHECKSUM 69 LOG_FILES 46 MAXLOGFILES 43, 46 MAXLOGMEMBERS 46 OPTIMIZER_MODE 77 specifying 31 configuring SQL Server 2005 and 2008 83 CONSISTENT export parameter 53 consistent whole backup 49 control files
ALTER DATABASE BACKUP CONTROLFILE 50 at database startup 36 backing up 49, 50 contents of 32 creation of 32 definition 26 managing 32 mounting the database 36 multiplexing 33 permanent damage 66 unavailable 62 using backup control file 66 CONTROLFILE option 50 creatddl.sql file 110 CREATE ROLLBACK SEGMENT command 39 CREATE ROLLBACK SEGMENT r01 TABLESPACE rbs1 39 CREATE TABLESPACE command 41 create.sql file 110 creating backup devices 91 data tablespaces 40 log groups 43 parameter files 32 redo log files 43 SQL Server filegroups 90 tablespaces 41 temporary backup devices 100 temporary tablespaces 41 cropping, indexes 74
D
data blocks coalescing free space 76 in logical structure 28 data dictionary taking offline 42 database administrator job functions
12
Index
database initialization parameters. See configuration parameters Database Maintenance Plan Wizard 105 database options 87 truncate log on checkpoint 96 database server, software for 11 databases deleting 103 managing files and filegroups 86 Oracle components 31 Oracle structure 26, 27 recovering 60 recovering from alternate location 61 recovering lost control files 66 re-creating for restore 103 restoring 101 shutting down 38 starting in restricted mode 37 tablespace distribution 38 datafiles adding 42 backing up 49 definition 26 determining if recovery is needed 61 RECOVER DATAFILE 60 recovering in SYSTEM tablespace 62 restoring to alternate location 64, 65 SQL Server 2005 and 2008 86 DBA_DATA_FILES view 64, 65 DBA_FREE_SPACE_COALESCED view 76 DBCC commands 105 Checkdb 105 DBReport utility 14 reading output 106 SQL Server 106 DBWR process 29 DDL scripts 14 DEFAULT STORAGE clause of CREATE TABLESPACE command 41 defining and using server groups 82
deleting databases 103 dependent objects dropping 109 re-creating 75, 110 distributed databases (Oracle option) drop.sql 74, 110 dropddl.sql 74 dropping dependent objects 74, 109 indexes 110 objects during maintenance 59 redo log files or log groups 44 rollback segments 63
29
E
ENABLE RESTRICTED SESSION 37 enabling a restricted session 37 Enterprise eTIME database backup devices for 90, 91 components in Oracle 31 configuation parameters for Oracle 32 creating filegroups for 90 creating tablespaces for 40 dropping indexes 110 exporting the schema 54 integrity checking 105 redo logs for 45 SQL Server backup devices 91 tablespace distribution 38 taking tablespaces offline 42 temporary backup devices 100 EXP_FULL_DATABASE role 54 export characteristics 52 complete 52 cumulative 52 incremental 52 export parameters CONSISTENT 53 FILE 53
Index
FULL 52, 53 GRANTS 53 INCTYPE 53 INDEXES 53 USER 54 Export utility command line 54 EXP_FULL_DATABASE role 54 for logical backups 51 help for 54 required rights 54 transfering files across systems 54 using 54 exporting the Enterprise eTIME schema 54 extents in segments 27
I
import 68 resetting ROWID values 69 inconsistent closed database backups 50 inconsistent whole database backup 50 incremental backups 12, 95 in SQL Server Management Studio 97 using SQL statements 97 with nonlogged operations 96 incremental exports 52 INCTYPE export parameter 53 indexes dropping 110 rebuilding 74, 109 re-creating 109 INDEXES export parameter 53 init*.ora files 31 after control file loss 66 initialization parameters. See configuration parameters instance recovery 58 recovery steps 59 structure of 28 integrity checking 22, 105
F
FILE export parameter 53 filegroups 86 creating in SQL Server 2005 and 2008 90 managing 89 files transaction log 89 free space coalescing 76 determining need for COALESCE 76 full backup 19 using SQL Server Management Studio 94 using SQL statements 94 FULL export parameter 53
L
LGWR process 29 database hangs 71 log files creating 43 log groups adding 43 adding redo log files 44 creating 43 dropping 44 LOG_ARCHIVE_DEST configuration parameter 47, 61 changing 56
G
GRANTS export parameter 53
H
hot backups 50, 100 ARCHIVELOGMODE 50
Index
LOG_ARCHIVE_DUPLEX_DEST configuration parameter 47 LOG_ARCHIVE_FORMAT configuration parameter 61 LOG_ARCHIVE_START configuration parameter 47 LOG_BLOCK_CHECKSUM configuration parameter 69 LOG_FILES configuration parameter 46 logical backups 51
control files 33 multithreading (Oracle option)
29
N
net send/users command 84 NOMOUNT startup option 37 nonlogged operations, with incremental backup 96 NT Instance Manager starting database from 37 NT Services panel to configure SQL Server 83
M
Maintenance Plan Wizard 111 Management Studio database management 84 login window 85 main window 85 managing control files 32 filegroups 89 parameter files 31 master database backing up 93 backing up with TRUNCATE_ONLY 98 backup strategies for 93 contents of 93 DBCC commands for 105 recovering 104 recovering from complete backup 102 MAXLOGFILES configuration parameter 43, 46 MAXLOGMEMBERS configuration parameter 46 media recovery 60 mounting the database 36 MSSQLServer service changing startup parameters 83 shutting down 84 startup parameters for 83 multiplexing
O
offline (cold) backups 49 online (hot) backups. See backups ONLINE option, of ALTER ROLLBACK SEGMENT command 39 online redo logs applying 61 archived 46 backing up 49 maximum files allowed 43 recovering corrupt 69 running out of logs 55 optimizer Oracle 77 OPTIMIZER _MODE configuration parameter 77 FIRST_ROWS 77 ora*.cfg files 31 Oracle databases components of 31 logical structure of 27 shutting down 38 Oracle Parallel Server 29 Oracle processes 28 Oracle template file, default location 32 ORACLE_HOME logical name 31
10
Index
P
parameter files at database startup 36 backing up 49 creating 32 definition 26 definition of 31 for export 52 managing 31 naming conventions for 31 parameters for Enterprise eTIME database 32 required parameters 32 template file for 32 partial backups 55 password files, backing up 49 PCTINCREASE 76 physical backups 48 contents of 48 full 48 partial backups 49 physical storage structure, Oracle 26 privileges changing archive destination 56 Process Monitor (PMON) process 29 processes, Oracle 28 production databases damage to 17 upgrade failures 17 viruses 17 Program Global Area (PGA) 28
R
Recomp utility Oracle 78 recompiling stored procedures 21, 78 RECOVER DATABASE command, USING BACKUP CONTROLFILE 66 recovering
corrupt online redo logs 69 datafiles 60 datafiles in SYSTEM tablespace 62 entire database 60 from alternate location 61 log files 61 lost control file 66 master database 104 missing online redo logs files 63 online redo logs 61 tablespaces 60, 64 unavailable control file 62 recovery automatic 101 checkpoints with 99 datafiles needed. 61 instance 58 media 60 point-in-time 102 strategies 19, 62 re-creating databases 103 SQL Server 2005 and 2008 103 dependent objects 75, 109, 110 dropped objects 110 indexes 109 redo log files or log groups 44 recreating lost database 66 redo log files 43 adding to log group 44 dropping 44 recovering 63 size forEnterprise eTIME database 45 redo log groups creating 43 losing 55 redo logs creating 43 dropping and re-creating 44
11
Index
location of 43 STALE status 45 RENAME DATAFILE 64, 65 resetting ROWID values 69 restoring tablespaces 65 through a complete backup 102 restoring databases preparing for 101 when the database must be re-created 103 when the database must be recreated 66 restricted session enabling 37 starting 37 rights for export 54 rollback segments dropping after failure 63 failure 63 number needed 39 placing online 39 restoring 65 rollback tablespaces backup frequency 55 names for 39 size of 39
S
schema objects, Oracle 27 segments extents for 27 in tablespaces 27 Server Manager multiple connections at shutdown SHUTDOWN command 38 starting a database 36 servers processes 28 SHUTDOWN command 38 ABORT 38
38
IMMEDIATE 38 NORMAL 38 Server Manager 38 WITH NOWAIT 84 shutting down broadcasting message 84 databases 38 MSSQLServer service 84 SQL Server from the Management Studio SID, in parameter file name 31 SMON process during instance recovery 59 tablespace coalescence 76 SQL Server 2005 and 2008 configuring 83 filegroups 90 sequence to stop 83 starting in single user mode 104 SQL Server Management Studio 81 scheduling backups 111 starting a database account for 36 for normal use 36 from NT Instance Manager 37 in restricted mode 37 starting SQL Server 2005 and 2008 automatically at start time 83 in single user mode 104 starting SQL Server from the Management Studio 82 STARTUP command account for 36 NOMOUNT 37 NT Instance Manager 37 Server Manager 36 without opening database 37 startup parameters changing MSSQLServer 83 MSSQLServer 83 Stats utility 14, 77
84
12
Index
Oracle 77 stored procedures recompiling 21 System Global Area at database start 36 SYSTEM tablespace backup frequency 55 lost datafile 62 permanent loss 65
V$DATAFILE view 61 V$LOG view 44 V$LOGFILE view 45 V$RECOVER_FILE view 61 V$SESSION_WAIT view 72 VALIDATE REF UPDATE, to update ROWID values 69 viruses 17
W T
tablespaces adding datafiles 42 backing up separately 50 coalescing free space 76 creating 40 distribution for Enterprise eTIME database 38 loss of SYSTEM tablespace 65 recovering 60 syntax for creating 41 taking offline 42 taking offline for recovery 64 temporary 41 temporary backup devices 100 transaction logs backing up 95 disk space requirements 89 managing 89 too full 99 TRUNCATE_ONLY option 98 whole database backup, restoring missing files from 64 Windows scheduling facility 111 WITH NO _INFOMSGS (DBCC option) 105
U
updating statistics Oracle 77 USER export parameter user processes 28 54
13

Database Administrators Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Database Administrators Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Database Administrators Guide

A database administrators guide to the Workforce Central system.

Kronos Workforce Central Suite Version 6.3