311 TABLESPACE data DISABLE STORAGE IN ROW INDEX clob_index); Table created. INSERT INTO clob_test_table VALUES (1, ‘This is another test’); 1 row created. SELECT * FROM clob_test_table; ID CLOB_COLUMN ---------- ------------------------------ 1 This is another test UPDATE clob_test_table set clob_column=’This is a changed column’ WHERE id=1; 1 row updated. SELECT * FROM clob_test_table; ID CLOB_COLUMN ---------- ------------------------------ 1 This is a changed column DELETE FROM clob_test_table where clob_column=’This is a changed column’; DELETE FROM clob_test_table where clob_column=’This is a changed column’ * ERROR at line 1: ORA-00932: inconsistent datatypes SQL> SELECT * FROM clob_test_table WHERE clob_column LIKE ‘%This%’; SELECT * FROM clob_test_table WHERE clob_column LIKE ‘%This%’ * ERROR at line 1: ORA-00932: inconsistent datatypes MANAGING DATABASE OBJECTS THAT SUPPORT TABLES AND INDEXES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 7 • ORACLE DATABASE MAINTENANCE 312 Notice that some SQL operations work just fine, but others don’t work correctly. It’s those problematic operations that the DBMS_LOB package is made for! The Oracle- supplied package provides various routines that can be used to manage and manipu- late Oracle internal and external LOBs. Viewing LOB Information Several data dictionary views provide information about LOBs, such as the column name of the LOB, the LOB segment name, and the chunk size. Table 7.2 describes these data dictionary views. TABLE 7.2: DATA DICTIONARY VIEWS FOR LOBS View Description DBA_LOBS Contains various information on LOBs, such as the name of the table that contains the LOB, the name of the LOB column, and so on DBA_LOB_PARTITIONS Contains partition-specific Information on LOBs in table partitions DBA_LOB_SUBPARTITIONS Contains partition-specific Information on LOBs in table subpartitions DBA_PART_LOBS Contains default partition settings for LOBs in table partitions V$TEMPORARY_LOBS Contains Information on temporary LOBs Understanding Database Startup and Shutdown It is important to understand the process of starting up and shutting down the data- base. This is because you will want the database to be in different modes for different types of recoveries (which are discussed in Chapter 10). In this section, we will discuss the various stages of database startup and shutdown. Starting Up the Database When you issue the STARTUP command on an Oracle database, it goes through three distinct stages: NOMOUNT, MOUNT, and OPEN. Several events occur during these stages as the database prepares to open. Database checks, datafile checks, consistency Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 313 checks, and certain types of recoveries occur during the startup process. Another startup mode that is available to the DBA is restricted mode. In executing various tasks, it may (and will likely) be necessary for you to start the database in a mode other than OPEN mode. NOMOUNT Mode NOMOUNT mode, and the NOMOUNT stage of regular startup, is essentially only the startup of the Oracle instance. As Oracle proceeds through the NOMOUNT stage, it performs the following steps: 1. It locates the database parameter file. By default, it will look for the init.ora file in the $ORACLE_HOME/dbs directory on Unix systems or the $ORACLE_HOME\ database directory on Windows NT. TIP You can use the PFILE parameter in the STARTUP command to designate an alter- nate location for the parameter file. An example of using the STARTUP command with the PFILE parameter might look something like this: STARTUP NOMOUNT PFILE= d:\oracle\ admin\database\pfile\init(sid).ora . 2. Oracle will open and read the parameter file, and then process and validate the parameters. 3. Oracle will allocate the SGA it will require to crank up the instance. 4. Oracle will proceed to start the processes of the instance, such as DBWR, LGWR, CKPT, SMON, and PMON. Once the instance is started, the NOMOUNT phase of opening the database will have concluded. You will start the database in NOMOUNT mode in just a few cases. First, you will start the instance in this manner when you wish to create a new database (or re-create an old one). Second, you will start the instance in this mode when you need to create a control file using the CREATE CONTROL FILE command (discussed in Chapter 10). To cause the database startup process to proceed only through the NOMOUNT stage and halt, issue the STARTUP NOMOUNT command from the Server Manager or SQL*Plus prompt. You will note that when you start up the instance, the amount of memory allo- cated to the SGA is reported. Generally, the memory reported looks something like this (obviously the sizes of memory allocated will differ): UNDERSTANDING DATABASE STARTUP AND SHUTDOWN Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 7 • ORACLE DATABASE MAINTENANCE 314 Total System Global Area 92280076 bytes Fixed Size 70924 bytes Variable Size 87937024 bytes Database Buffers 4194304 bytes Redo Buffers 77824 bytes The Fixed Size entry shows the memory allocated to a small portion of the SGA that contains database and instance status information required by background processes. The Variable Size entry shows the overall size of the shared pool area. It is also influenced by the use of the large pool and Java pool sizes. The other entries are self-explanatory. This output can also be retrieved by using the SHOW SGA command or viewed in the V$SGA data dictionary view (which is the source of the output). NOTE The Redo Buffers entry in this output may not match the setting in the init.ora file for your database. This is because there is a minimum setting for the redo log buffer of four times the maximum database block size for the system. MOUNT Mode Once the instance has been started, the next step in opening the database associated with that instance is to mount the database. In MOUNT mode (and during the MOUNT stage), Oracle locates and opens the control file of the database. It is also at the MOUNT stage that database media recovery occurs (if the database needs to be recovered while it is down). To start the database in MOUNT mode, use the STARTUP MOUNT command. You might do this for several reasons: to put the database in ARCHIVELOG mode, to per- form certain recovery operations, or to rename database datafiles. If you wish to open the database in this mode, issue the command ALTER DATABASE OPEN. OPEN Mode During the OPEN stage, Oracle takes the final steps to open the database. The datafiles are opened, and an error will be signaled if a datafile is missing or if Oracle is unable to open it for some other reason. Once the database datafiles are opened, Oracle will check them with the control file to make sure that the database was closed in a con- sistent fashion. If it was, Oracle will open the database for use. If the database was not closed in a normal fashion, Oracle will decide if instance or media recovery is required. If instance recovery is required, Oracle will perform it automatically without any user interaction. During instance recovery, Oracle will apply the redo in the online redo logs to the database, open the database, and roll back any uncommitted transactions Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 315 after the database is open. The process of rolling back transactions while the database is open is known as fast start recovery. Fast start recovery allows the database to be used while instance recovery is ongoing. During fast start recovery, the SMON process will roll back the uncommitted transactions, allowing users access to the database at the same time. In Oracle8i, SMON can actually take advantage of parallel processing while performing these operations. NOTE During fast start recovery, a new feature in Oracle8i allows Oracle user processes to prioritize the recovery of specific, in demand blocks. Thus, user processes will not need to wait for SMON to recover a block, which can take some time during particularly large recovery operations. A user process will determine that the block needs recovery and will take care of that block’s recovery itself. If Oracle needs to apply media recovery, it will inform the user that media recovery is required. Oracle will not open the database in this case, and will return to the SQL prompt to allow the DBA to begin media recovery. See Chapter 10 for information about media recovery. Restricted Mode You (as the DBA) can put the database in restricted mode if the database needs to be open for some maintenance operation but you do not want users to be able to con- nect to the database. To start the database in restricted mode, issue the STARTUP RESTRICT command. If the database is already open and you wish to put it in restricted mode, you can issue the command ALTER SYSTEM ENABLE RESTRICTED SESSION. Restricted mode impacts only new logins to the database, so existing users will need to be disconnected to ensure that no one can make changes to the database. Once you have completed your maintenance operations, you can take the database out of restricted mode by issuing the ALTER SYSTEM DISABLE RESTRICTED SESSION command. Also, if you shut down the database and restart it normally, it will no longer be in restricted mode. Shutting Down the Database The normal Oracle database shutdown sequence is much like the startup sequence, just in reverse order. First the database is dismounted. During a normal shutdown, the database waits for all sessions to disconnect (while preventing new sessions from connecting to the database). Once all sessions discon- nect (which has the result of determining the state of all transactions at shutdown UNDERSTANDING DATABASE STARTUP AND SHUTDOWN Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 7 • ORACLE DATABASE MAINTENANCE 316 time), the database datafiles are checkpointed and then closed. The checkpoint process is very important because it leaves the database datafiles in a consistent state, allowing the database to start up the next time without the database (or the DBA) needing to perform any type of recovery. (See Chapter 5 for more on checkpoints and the consistent state of the database.) The database then proceeds through the dismount phase, in which the control file is closed. Finally, the instance is terminated with the normal shutdown of the Oracle processes and de-allocation of the SGA. Along with the normal SHUTDOWN command, several other commands may be used to shut down the database, as explained in the following sections. SHUTDOWN ABORT A SHUTDOWN ABORT is essentially a crash of the database. At a minimum, this type of shutdown will result in an instance recovery when the database is restarted. The main difference between a SHUTDOWN ABORT and just pulling the plug on the data- base is that the database datafiles are closed normally (although they are not check- pointed in any way) and memory is de-allocated from the system in a somewhat controlled fashion. The normal closing of the database datafiles is perhaps a bit safer than just pulling the plug on a database. SHUTDOWN IMMEDIATE The SHUTDOWN IMMEDIATE command will cause all existing user processes to be terminated, following which a normal shutdown will ensue. All existing uncommit- ted transactions will be rolled back before the database is shut down, which can take some time to complete. Another thing that can slow down a SHUTDOWN IMMEDI- ATE is an ongoing instance recovery process. You can get an idea of how long a SHUTDOWN IMMEDIATE will take by looking at the V$TRANSACTION table’s USED_UBLK or USED_UREC column, which repre- sents the total amount of undo that will need to be reapplied to the database datafiles before the database can shut down. Ongoing instance recovery processes will not show up in V$TRANSACTION. To see those, you can try looking at the V$SESSION_ LONGOPS or V$RECOVERY_PROGRESS view, although neither of these may provide any information, depending on how much recovery Oracle is expecting to do. SHUTDOWN TRANSACTIONAL The SHUTDOWN TRANSACTIONAL command allows the user transaction to com- plete before signing off the user. Thus, if a user application is in the middle of making some change, the database will wait for a commit to occur before disconnecting the Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 317 session. This can pose a problem if a transaction is being manually executed and the user doesn’t commit that transaction for a long period of time. When You Have the Choice—SHUTDOWN ABORT or SHUTDOWN IMMEDIATE? When you need to shut down the database for normal maintenance operations, should you use SHUTDOWN ABORT or SHUTDOWN IMMEDIATE? This is another of those ques- tions that everyone has an opinion about. There are those that take the position that a SHUTDOWN ABORT is just fine. It shortens the time for the outage, even though you know that the database will need to perform instance recovery when starting back up, However, there are problems with using SHUTDOWN ABORT to shut down the data- base for normal maintenance operations. What happens if you use SHUTDOWN ABORT, and then you accidentally remove all the copies of the current online redo log (or per- haps the system administrator accidentally wipes out the volumes or disks with these critical files on them)? Since the database was not shut down cleanly, it’s going to need to perform instance recovery, which will not be possible without the current online redo log. Since the log file was the current log file, it will not yet have been archived, so there is no copy of it anywhere. Your database is now beyond recovery, unless you have some way to recover those online redo log files that were just removed. Another issue with SHUTDOWN ABORT has to do with some nasty behavior in Oracle (I think it’s a bug) involving the TRUNCATE command. Suppose that you create a table and add a large number of records to it. Now, say that after you have entered all these records (but with no commit), the database is shut down with a SHUTDOWN ABORT command. Now, the database starts up and instance recovery begins. Let’s say that you decide (or perhaps another user does) to truncate the table. Of course, records in this table are being rolled back by the instance recovery process. If you try to truncate the table that is being rolled back during instance recovery, you will crash the database. And we don’t just mean the one user session—the entire database will crash. My point with all of this is that SHUTDOWN ABORT introduces too many variables into the equation. Probably 99.9 percent of the time, everything will be okay, but that one time in a thousand always seems to hit me. We try not to perform SHUTDOWN ABORTs for normal maintenance unless there is some emergency that requires an immediate database termination. If we do decide to do a SHUTDOWN ABORT, we generally try to force a log switch (ALTER SYSTEM SWITCH LOGFILE) on the database and then force a UNDERSTANDING DATABASE STARTUP AND SHUTDOWN Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 7 • ORACLE DATABASE MAINTENANCE 318 checkpoint (ALTER SYSTEM CHECKPOINT) as well, before issuing the SHUTDOWN ABORT command. My personal preference is the SHUTDOWN IMMEDIATE command. This has the impact of killing all user sessions, rolling back all uncommitted transactions, and then closing the database datafiles normally (with a checkpoint to boot!). When this mode is selected, the database will be shut down cleanly. You can lose the online redo log files and still be in good shape. Before performing a SHUTDOWN IMMEDIATE, we do a log switch. After the shutdown, if major system work is about to be performed (particularly if that system work involves disks), we back up all archived redo logs before we allow the work to begin. The downside of this is that the SHUTDOWN IMMEDIATE command (along with my suggestion of a log switch) generally will take longer to complete than the SHUT- DOWN ABORT command will. The solution is to allow sufficient time to shut down the system, and coordinate the shutdown with the user community, so that a minimum number of transactions are occurring on the database when the shutdown occurs. Changing the Database Name If you need to, you can change the name of your database. You probably should not make a habit of this, but there may be times that you really don’t have a choice. Changing the name of your database is a fairly straightforward process: 1. Issue the ALTER DATABASE BACKUP CONTROLFILE TO TRACE command. This will create a trace file in the UDUMP directory that will allow you to re-create the control file, which is required to rename the database. 2. Issue the SHUTDOWN IMMEDIATE or SHUTDOWN command for a consistent database shutdown. 3. Modify the trace file created in step 1. It should just contain the text of the CRE- ATE CONTROL FILE statement. You will need to replace the REUSE statement with SET on the first line of the statement. Also, change the NORESETLOGS com- mand to RESETLOGS. When you are finished, it should look something like this: CREATE CONTROLFILE SET DATABASE “ORA817” RESETLOGS ARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 3 MAXDATAFILES 254 Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 319 MAXINSTANCES 1 MAXLOGHISTORY 899 LOGFILE GROUP 1 ‘D:\ORACLE\ORADATA\ORA817\REDO01.LOG’ SIZE 1M, GROUP 2 ‘D:\ORACLE\ORADATA\ORA817\REDO02.LOG’ SIZE 1M, GROUP 3 ‘D:\ORACLE\ORADATA\ORA817\REDO03.LOG’ SIZE 1M DATAFILE ‘D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\RBS01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\USERS01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\TEMP01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\TOOLS01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\INDX01.DBF’, ‘D:\ORACLE\ORADATA\ORA817\TEMPTEMP01.DBF’ CHARACTER SET WE8ISO8859P1; 4. Back up the physical database control file. (It’s always a good idea to make sure that you have a current backup of the database as well!) Remove the control file after backing it up. 5. If you are using Windows NT, you will need to stop the database service and then edit it to rename the service. Then restart the service. Perform these actions with ORADIM. (See Chapter 3 for more on ORADIM.) 6. You will need to rename the database parameter file and change any database name references inside that file, such as the database name, instance name, and service names. 7. If you are using a password file, you will need to rename the old password file. 8. Change your ORACLE_SID so that it is pointing to the new database name. 9. Issue a STARTUP NOMOUNT command to start the database in NOMOUNT mode. Execute the script you created in step 3. 10. After running the script, issue the RECOVER DATABASE command (if your are in ARCHIVELOG mode and did not shut down the database cleanly). Then issue the ALTER DATABASE OPEN RESETLOGS command. Your database should open normally. 11. Change the global name of your database with the ALTER DATABASE RENAME GLOBAL_NAME command, like this. ALTER DATABASE RENAME GLOBAL_NAME TO newname; 12. Make another backup of your database. CHANGING THE DATABASE NAME Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 7 • ORACLE DATABASE MAINTENANCE 320 Managing Database Files After you have your database up and running, you will need to manage various data- base files. Your datafiles may need some attention, and you might want to add a con- trol file. Also, there may be cases where you need to move online redo logs. These topics are covered here. Managing Datafiles Your datafiles are defined with the tablespace that contains them. However, if neces- sary, you can move and resize them. Also, Oracle provides some data dictionary views that provide information about database datafiles. Moving Datafiles To move a datafile with the database up and running, you must first be in ARCHIVELOG mode. To move a datafile that is assigned to a tablespace, follow these steps: 1. Take the datafile offline. 2. Physically move it to the new file system. 3. Alter the datafile location internal to Oracle with the ALTER DATABASE RENAME FILE command. 4. Bring the datafile back online. Listing 7.4 provides an example of moving an existing datafile. Listing 7.4: Moving a Database Datafile -- First, take the datafile offline. ALTER DATABASE DATAFILE ’d:\oracle\oradata\recover\recover_my_extending_tablespace_01.dbf’ OFFLINE; -- Now, copy the datafile. Host copy d:\oracle\oradata\recover\recover_my_extending_tablespace_01.dbf e:\oracle\oradata\recover\recover_my_extending_tablespace_01.dbf -- Now, rename it in the database. ALTER DATABASE RENAME FILE ’d:\oracle\oradata\recover\recover_my_extending_tablespace_01.dbf’ Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.