OCA/OCP Oracle Database 11g All-in-One Exam Guide 116 At any stage, how does the instance find the files it needs, and exactly what happens? Start with NOMOUNT. When you issue a startup command, Oracle will attempt to locate a parameter file using a systematic ordered search as depicted in Figure 3-8. There are three default filenames. On Unix they are $ORACLE_HOME/dbs/spfileSID.ora $ORACLE_HOME/dbs/spfile.ora $ORACLE_HOME/dbs/initSID.ora and on Windows, %ORACLE_HOME%\database\SPFILESID.ORA %ORACLE_HOME%\database\SPFILE.ORA %ORACLE_HOME%\database\INITSID.ORA Figure 3-8 Sequential search for an instance parameter file during STARTUP Chapter 3: Instance Management 117 PART I TIP spfileSID.ora is undoubtedly the most convenient file to use as your parameter file. Normally, you will only use spfile.ora in a RAC environment, where one file may be used to start several instances. You will generally only use an initSID.ora file if for some reason you need to make manual edits using a text editor; spfiles are binary files and cannot be edited by hand. In all cases, SID refers to the name of the instance that the parameter file will start. The preceding order is important! Oracle will work its way down the list, using the first file it finds and ignoring the rest. If none of them exist, the instance will not start. The only files used in NOMOUNT mode are the parameter file and the alert log. The parameters in the parameter file are used to build the SGA in memory and to start the background processes. Entries will be written out to the alert log describing this process. Where is the alert log? In the location given by the BACKGROUND_DUMP_ DEST parameter, that can be found in the parameter file or by running sho parameter background_dump_dest from a SQL*Plus prompt once connected as a privileged user. If the alert log already exists, it will be appended to. Otherwise, it will be created. If any problems occur during this stage, trace files may also be generated in the same location. EXAM TIP An “init” file is known as a “static” parameter file or a pfile, because it is only read once, at instance startup. An “spfile” is known as a dynamic parameter file, because Oracle continuously reads and updates it while the instance is running. A parameter file of one sort or the other is essential, because there is one parameter without a default value: the DB_NAME parameter. Once the instance is successfully started in NOMOUNT mode, it may be transitioned to MOUNT mode by reading the controlfile. It locates the controlfile by using the CONTROL_FILES parameter, which it knows from having read the parameter file used when starting in NOMOUNT mode. If the controlfile (or any multiplexed copy of it) is damaged or missing, the database will not mount and you will have to take appropriate action before proceeding further. All copies of the controlfile must be available and identical if the mount is to be successful. As part of the mount, the names and locations of all the datafiles and online redo logs are read from the controlfile, but Oracle does not yet attempt to find them. This happens during the transition to OPEN mode. If any files are missing or damaged, the database will remain in MOUNT mode and cannot be opened until you take appropriate action. Furthermore, even if all the files are present, they must be synchronized before the database opens. If the last shutdown was orderly, with all database buffers in the database buffer cache being flushed to disk by DBWn, then everything will be synchronized: Oracle will know that that all committed transactions are safely stored in the datafiles, and that no uncommitted transactions are hanging about waiting to be rolled back. However, if the last shutdown was disorderly (such as from a loss of power, or the server being accidently rebooted), then Oracle must repair the damage and the database is considered to be in an inconsistent state. The mechanism for this is described in Chapter 14. The process that OCA/OCP Oracle Database 11g All-in-One Exam Guide 118 mounts and opens the database (and carries out repairs, if the previous shutdown was disorderly) is the SMON process. Only once the database has been successfully opened will Oracle permit user sessions to be established. The startup process just described is graphically summarized in Figure 3-9. Figure 3-9 High-level steps followed during an instance startup Chapter 3: Instance Management 119 PART I Shutdown should be the reverse of startup. During an orderly shutdown, the database is first closed, then dismounted, and finally the instance is stopped. During the close phase, all sessions are terminated: active transactions are rolled back by PMON, completed transactions are flushed to disk by DBWn, and the datafiles and redo logfiles are closed. During the dismount, the controlfile is closed. Then the instance is stopped by deallocating the SGA memory and terminating the background processes. TIP If someone were in the middle of a long-running uncommitted statement (for example, they were loading tables for a data warehouse), when you had to shut down the database, the rollback phase, and therefore the time it takes the database to close and shut down cleanly, could be a very long time. Shutdown: NORMAL, TRANSACTIONAL, IMMEDIATE, and ABORT There are options that may be used on the shutdown command, all of which require either a SYSDBA or a SYSOPER connection: shutdown [normal | transactional | immediate | abort] Normal: This is the default. No new user connections will be permitted, but all current connections are allowed to continue. Only once all users have (voluntarily!) logged off, will the database actually shut down. TIP Typically, a normal shutdown is useless: there is always someone logged on, even if it is only the Database Control process. Transactional: No new user connections are permitted; existing sessions that are not actively performing a transaction will be terminated; sessions currently involved in a transaction are allowed to complete the transaction and will then be terminated. Once all sessions are terminated, the database will shut down. Immediate: No new sessions are permitted, and all currently connected sessions are terminated. Any active transactions are rolled back, and the database will then shut down. Abort: As far as Oracle is concerned, this is the equivalent of a power failure. The instance terminates immediately. Nothing is written to disk, no file handles are closed, and there is no attempt to terminate transactions that may be in progress in any orderly fashion. TIP A shutdown abort will not damage the database, but some operations (such as backups) are not advisable after an abort. The “normal,” “immediate,” and “transactional” shutdown modes are usually referred to as “clean,” “consistent,” or “orderly” shutdowns. After all sessions are OCA/OCP Oracle Database 11g All-in-One Exam Guide 120 terminated, PMON will roll back any incomplete transactions. Then a checkpoint is issued (remember the CKPT process from Chapter 1), which forces the DBWn process to write all updated data from the database buffer cache down to the datafiles. LGWR also flushes any change vectors still in memory to the logfiles. Then the file headers are updated, and the file handles closed. This means that the database is in a “consistent” state: all committed transactions are in the datafiles, there are no uncommitted transactions hanging about that need to be rolled back, and all datafiles and logfiles are synchronized. The “abort” mode, sometimes referred to as a “disorderly” shutdown, leaves the database in an “inconsistent” state: it is quite possible that committed transactions have been lost, because they existed only in memory and DBWn had not yet written them to the datafiles. Equally, there may be uncommitted transactions in the datafiles that have not yet been rolled back. This is a definition of a corrupted database: it may be missing committed transactions, or storing uncommitted transactions. These corruptions must be repaired by instance recovery (described in Chapter 14). It is exactly as though the database server had been switched off, or perhaps rebooted, while the database was running. TIP There is a startup command startup force that can save time. It is two commands in one: a shutdown abort followed by a startup. An orderly shutdown is a staged process, and it is possible to control the stages using the SQL*Plus: alter database close; alter database dismount; These commands are exactly the reverse of the startup sequence. In practice, however, there is little value to them; a shutdown is generally all any DBA will ever use. The staged shutdown commands are not even available through Database Control. Exercise 3-2: Conduct a Startup and a Shutdown Use SQL*Plus to start an instance and open a database, then Database Control to shut it down. If the database is already open, do this in the other order. Note that if you are working on Windows, the Windows service for the database must be running. It will have a name of the form OracleServiceSID, where SID is the name of the instance. 1. Log on to the computer as a member of the operating system group that owns the ORACLE_HOME, and set the environment variables appropriately for ORACLE_HOME and PATH and ORACLE_SID, as described in Chapter 2. 2. Check the status of the database listener, and start it if necessary. From an operating system prompt: lsnrctl status lsnrctl start Chapter 3: Instance Management 121 PART I 3. Check the status of the Database Control console, and start it if necessary. From an operating system prompt: emctl status dbconsole emctl start dbconsole 4. Launch SQL*Plus, using the /nolog switch to prevent an immediate logon prompt: sqlplus /nolog 5. Connect as SYS with operating system authentication: connect / as sysdba 6. Start the instance only. Then query the V$INSTANCE view and examine its STATUS column. Note that the status of the instance is “STARTED”. startup nomount; select status from v$instance; 7. Mount the database and query the instance status. The database has now been “MOUNTED” by the instance. alter database mount; select status from v$instance; 8. Open the database: alter database open; 9. Confirm that the database is open by querying V$INSTANCE. The database should now be “OPEN”. select status from v$instance; 10. From a browser, connect to the Database Control console. The hostname and port will have been shown in the output of the emctl status dbconsole command in Step 3. The URL will be of the format: https://hostname: port/em. 11. Log on as SYS with the password selected at database creation, and choose SYSDBA from the Connect As drop-down box. 12. On the database home page, click the SHUTDOWN button. 13. The next window prompts for host credentials, which will be your operating system username and password, and database credentials, which will be the SYS username and password. If you want to save these to prevent having to enter them repeatedly, check the box Save As Preferred Credential. Click OK. Use the Alert Log and Trace Files The alert log is a continuous record of critical operations applied to the instance and the database. Its location is determined by the instance parameter BACKGROUND_ DUMP_DEST, and its name is alert_SID.log, where SID is the name of the instance. OCA/OCP Oracle Database 11g All-in-One Exam Guide 122 The critical operations recorded in the alert log include • All startup and shutdown commands, including intermediate commands such as ALTER DATABASE MOUNT • All errors internal to the instance (for example, any ORA-600 errors) • Any detected datafile block corruptions • Any record locking deadlocks that may have occurred • All operations that affect the physical structure of the database, such as creating or renaming datafiles and online redo logfiles • All ALTER SYSTEM commands that adjust the values of initialization parameters • All log switches and log archives The alert log entry for a startup shows all the nondefault initialization parameters. This information, together with the subsequent record of changes to the instance made with ALTER SYSTEM commands and to the database physical structures made with ALTER DATABASE commands, means that it is always possible to reconstruct the history of changes to the database and the instance. This can be invaluable when trying to backtrack in order to find the source of a problem. TIP For many DBAs, the first thing they do when they are asked to look at a database for the first time is locate the alert log and scan through it, just to get an idea of what has been going on. Trace files are generated by the various background processes, usually when they encounter an error. These files are located in the BACKGROUND_DUMP_DEST directory, along with the alert log. If a background process has failed because of an error, the trace file generated will be invaluable in diagnosing the problem. Exercise 3-3: Use the Alert Log In this exercise, locate the alert log and find the entries for the parameter changes made in Exercise 3-1 and the startups and shutdowns in Exercise 3-2. 1. Connect to your database with either SQL*Plus or SQL Developer, and find the value of the BACKGROUND_DUMP_DEST parameter: select value from v$parameter where name='background_dump_dest'; Note that this value can also be found with Database Control. 2. Using whatever operating system tool you please (such as Windows Explorer, or whatever file system browser your Linux session is using), navigate to the directory identified in Step 1. 3. Open the alert log. It will be a file called alert_SID.log, where SID is the name of the instance. Use any editor you please (but note that on Windows, Notepad is not a good choice because of the way carriage returns are handled. WordPad is much better). 4. Go to the bottom of the file. You will see the ALTER SYSTEM commands of Exercise 3-1 and the results of the startup and shutdowns. Chapter 3: Instance Management 123 PART I Use Data Dictionary and Dynamic Performance Views An Oracle database is defined by its data dictionary. The data dictionary is not very comprehensible. For this reason, Oracle provides a set of views onto the data dictionary that are much easier to understand. These views provide the DBA with a tool for understanding what is happening in the database. The instance also has a set of tables (which are in fact C data structures) that are not easily understandable. These are externalized as the dynamic performance views that are key to understanding what is happening within the instance. The Data Dictionary Views The data dictionary contains metadata: that is, data about data. It describes the database, both physically and logically, and its contents. User definitions, security information, integrity constraints, and (from release 10g onward) performance monitoring information are all part of the data dictionary. It is stored as a set of segments in the SYSTEM and SYSAUX tablespaces. In many ways, the segments that make up the data dictionary are like other regular table and index segments. The critical difference is that the data dictionary tables are generated at database creation time, and you are not allowed to access them directly. There is nothing to stop an inquisitive DBA from investigating the data dictionary directly, but if you do any updates to it you may cause irreparable damage to your database, and certainly Oracle Corporation will not support you. Creating a data dictionary is part of the database creation process. It is maintained subsequently by Data Definition Language (DDL) commands. When you issue the CREATE TABLE command, you are not only creating a data segment to store your data in its rows, your DDL command has the side effect of inserting rows into many data dictionary tables that keep track of segment-related information including tablespace, extent, column and ownership related properties. To query the dictionary, Oracle provides a set of views which come in three forms, prefixed with: DBA_, ALL_, or USER_. Most of the views come in all three forms. Any view prefixed USER_ will be populated with rows describing objects owned by the user querying the view. So no two users will see the same contents. When user JOHN queries USER_TABLES, he will see information about only his tables; if you query USER_TABLES, you will see information about only your tables. Any view prefixed ALL_ will be populated with rows describing objects to which you have access. So ALL_TABLES will contain rows describing your own tables, plus rows describing tables belonging to anyone else that you have been given permission to see. Any view prefixed DBA_ will have rows for every object in the database, so DBA_TABLES will have one row for every table in the database, no matter who created it. Figure 3-10 describes the underlying concept represented by the three forms of dictionary views. The USER_ views sit in the middle of the concentric squares and only describe an individual user’s objects. The ALL_ views in the middle display all the contents of the USER_ views, and in addition describe objects that belong to other schemas but to which your user has been granted access. The DBA_ views describe all objects in the database. Needless to say, a user must have DBA privileges to access the DBA_ views. OCA/OCP Oracle Database 11g All-in-One Exam Guide 124 These views are created as part of the database creation process, along with a large number of PL/SQL packages that are provided by Oracle to assist database administrators in managing the database and programmers in developing applications. TIP Which view will show you ALL the tables in the database? DBA_TABLES, not ALL_TABLES. There are hundreds of data dictionary views. Some of those commonly used by DBAs are • DBA_OBJECTS A row for every object in the database • DBA_DATA_FILES A row describing every datafile • DBA_USERS A row describing each user • DBA_TABLES A row describing each table • DBA_ALERT_HISTORY Rows describing past alert conditions There are many more than these, some of which will be used in later chapters. Along with the views, there are public synonyms onto the views. A query such as this, select object_name,owner, object_type from dba_objects where object_name='DBA_OBJECTS'; shows that there is, in fact, a view called DBA_OBJECTS owned by SYS, and a public synonym with the same name. The Dynamic Performance Views There are more than three hundred dynamic performance views. You will often hear them referred to as the “Vee dollar” views, because their names are prefixed with “V$”. In fact, the “Vee dollar” views are not views at all—they are synonyms to views that are prefixed with “V_$”, as shown in Figure 3-11. Figure 3-10 The overlapping structure of the three forms of the dictionary views Chapter 3: Instance Management 125 PART I The figure shows V$SQL, which has one row for every SQL statement currently stored in the shared pool, with information such as how often the statement has been executed. The dynamic performance views give access to a phenomenal amount of information about the instance, and (to a certain extent) about the database. The majority of the views are populated with information from the instance; while the remaining views are populated from the controlfile. All of them provide real-time information. Dynamic performance views that are populated from the instance, such as V$INSTANCE or V$SYSSTAT, are available at all times, even when the instance is in NOMOUNT mode. Dynamic performance views that are populated from the controlfile, such as V$DATABASE or V$DATAFILE, cannot be queried unless the database has been mounted, which is when the controlfile is read. By contrast, the data dictionary views (prefixed DBA, ALL, or USER) can only be queried after the database—including the data dictionary—has been opened. EXAM TIP Dynamic performance views are populated from the instance or the controlfile; DBA_, ALL_, and USER_ views are populated from the data dictionary. This difference determines which views can be queried at the various startup stages. The dynamic performance views are created at startup, updated continuously during the lifetime of the instance, and dropped at shutdown. This means they will accumulate values since startup time; if your database has been open for six months nonstop, they will have data built up over that period. After a shutdown/startup, they will be initialized. While the totals may be interesting, they do not directly tell you anything about what happened during certain defined periods, when there may have been performance issues. For this reason, it is generally true that the dynamic performance views give you statistics, not metrics. The conversion of these statistics into metrics is a skillful and sometimes time-consuming task, made much easier by the self-tuning and monitoring capabilities of the database. Figure 3-11 A V_$ view and its V$ synonym . views are created as part of the database creation process, along with a large number of PL/SQL packages that are provided by Oracle to assist database administrators in managing the database and. are $ORACLE_ HOME/dbs/spfileSID.ora $ORACLE_ HOME/dbs/spfile.ora $ORACLE_ HOME/dbs/initSID.ora and on Windows, %ORACLE_ HOME% database SPFILESID.ORA %ORACLE_ HOME% database SPFILE.ORA %ORACLE_ HOME% database INITSID.ORA Figure. been granted access. The DBA_ views describe all objects in the database. Needless to say, a user must have DBA privileges to access the DBA_ views. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 124 These