Less04 database instance

Editor's Notes

• #3: Oracle Database 11 g : Administration Workshop I 4 -
• #4: Oracle Database 11 g : Administration Workshop I 4 - Management Framework There are three major components of the Oracle database management framework: The database instance that is being managed A listener that allows connections to the database The management interface. This may be either a management agent running on the node where the database server runs (which connects it to Oracle Enterprise Manager Grid Control) or the stand-alone Oracle Enterprise Manager Database Control. This is also referred to as the Database Console . Each of these components must be started before you can use the services of the component and must be shut down cleanly when shutting down the server hosting the Oracle database.
• #5: Oracle Database 11 g : Administration Workshop I 4 - Starting and Stopping Database Control Oracle Database provides Database Control , which is a stand-alone management console for databases that are not connected to the Grid Control framework. Each database that is managed with Database Control has a separate Database Control installation; from any one Database Control, you can manage only one database. Before using Database Control, ensure that a dbconsole process is started. Command to start the dbconsole process: emctl start dbconsole Command to stop the dbconsole process: emctl stop dbconsole Command to view the status of the dbconsole process: emctl status dbconsole Note: You may need to navigate to your $ORACLE_HOME/bin directory if this directory is not in your operating system (OS) path. There are two $ORACLE_HOME locations if Grid Infrastructure is installed and both contain the emctl utility. The emctl utility should always be invoked using the Oracle database $ORACLE_HOME and not the Grid Infrastructure $ORACLE_HOME . Database Control uses a server-side agent process. This agent process automatically starts and stops when the dbconsole process is started or stopped.
• #6: Oracle Database 11 g : Administration Workshop I 4 - Oracle Enterprise Manager When you install the Oracle Database software, the Oracle Universal Installer (OUI) also installs Oracle Enterprise Manager (Enterprise Manager). Its Web-based Database Control serves as the primary tool for managing your Oracle database. Enterprise Manager provides a graphical interface for doing almost any task that you need to do as a database administrator (DBA). Viewing alert summaries and performance graphs, creating and modifying objects, and performing backup and recovery are some of the things that you can do with Enterprise Manager. In most cases, you can click links in Enterprise Manager to find more specific information about the contents of a page. Note: In Oracle Database 11 g Release 2, the URL to access Enterprise Manager uses HTTPS (instead of HTTP) as the protocol to enable a secure connection. To reach the Enterprise Manager dbconsole , you must therefore enter a URL in the following format: https://machine_name:port/em For the first database that you create on a machine, the default port number for accessing Enterprise Manager Database Control is 1158. It is possible to have different numbers, especially if there are multiple databases on the same host. To determine the port number, check the portlist.ini file. Ports for some Oracle Database applications are listed in the portlist.ini file, which is located in the $ORACLE_HOME/install directory.
• #7: Oracle Enterprise Manager (continued) When you enter the URL for Enterprise Manager, the content that is displayed depends on the status of the database: If the database is up , Enterprise Manager displays the Database Control Login page. Log in to the database by using a username that is authorized to access Database Control. Initially, this is SYS , SYSMAN , or SYSTEM . Use the password that you specified for the account during database installation. For the Connect As option, select either Normal or SYSDBA to log in to the database with special database administration privileges. If the database is down , Enterprise Manager displays the “Startup/Shutdown and Perform Recovery” page. If this is the case, click the Startup/Shutdown button. You are then prompted for the host and target database login usernames and passwords, which you must enter. Note: If you have trouble starting Enterprise Manager, ensure that a listener is started.
• #8: Oracle Database 11 g : Administration Workshop I 4 - Database Home Page The Database Home page displays the current state of the database by displaying a series of metrics that portray the overall health of the database. With the property pages (also referred to as tabs ), you can access the Performance, Availability, Server, Schema, Data Movement, and Software and Support pages for managing your database. You can view the following performance and status information about your database instance on the Database Home page: Instance name, database version, Oracle home location, media-recovery options, and other pertinent instance data Current instance availability Outstanding alerts Session-related and SQL-related performance information Key space-usage metrics Drill-down links (for example, LISTENER_< host_name > ) to provide increasing levels of detail
• #9: Oracle Database 11 g : Administration Workshop I 4 - Other Oracle Tools In addition to Enterprise Manager, you can use SQL*Plus and SQL Developer to issue SQL statements. These tools enable you to perform many of the database management operations as well as to select, insert, update, or delete data in the database. SQL*Plus is a command-line program that you use to submit SQL and PL/SQL statements to an Oracle database. You can submit statements interactively or as SQL*Plus scripts. SQL*Plus is installed with the database and is located in your $ ORACLE_HOME/bin directory. You can start SQL*Plus from the command line, or from the Start menu on a Windows client. SQL Developer is a graphical user interface for accessing your instance of Oracle Database. SQL Developer supports development in both the SQL and PL/SQL languages. It is available in the default installation of Oracle Database. With SQL Developer, you can browse database objects, run SQL statements and SQL scripts, and edit and debug PL/SQL statements. You can also run any number of provided reports, as well as create and save your own. Note: This course uses Enterprise Manager and SQL*Plus.
• #10: Oracle Database 11 g : Administration Workshop I 4 - Using SQL*Plus You can use the command-line interface of SQL*Plus to execute SQL*Plus, SQL, and PL/SQL commands to: Enter, edit, run, store, retrieve, and save SQL commands and PL/SQL blocks Format, calculate, store, and print query results List column definitions for any table Send messages to and accept responses from an end user Perform database administration To start SQL*Plus: 1. Open a terminal window. 2. At the command-line prompt, enter the SQL*Plus command in the following form: $ sqlplus <userid>/<pwd> or /nolog 3. If you use the NOLOG option, you must enter CONNECT followed by the username you want to connect as. SQL> connect <username> 4. When prompted, enter the user’s password. SQL*Plus starts and connects to the default database.
• #11: Oracle Database 11 g : Administration Workshop I 4 - Calling SQL*Plus from a Shell Script You can call SQL*Plus from a shell script or BAT file by invoking sqlplus and using the operating system scripting syntax for passing parameters. In this example, the SELECT , UPATE and COMMIT statements are executed before SQL*Plus returns control to the operating system.
• #12: Oracle Database 11 g : Administration Workshop I 4 - Calling a SQL Script from SQL*Plus You can call an existing SQL script file from within SQL*Plus. This can be done at the command line when first invoking SQL*Plus, as shown in the slide. It can also be done from inside a SQL*Plus session simply by using the “@” operator. For example, this runs the script from within an already established SQL*Plus session: SQL> @script.sql Note: The default file extension for script files is .sql . When a script is saved from SQL*Plus by using the save command, this extension is automatically supplied. Scripts with this extension can be executed even without supplying the extension at execution time, as in the following example: SQL> @script
• #13: Oracle Database 11 g : Administration Workshop I 4 - Initialization Parameter Files When you start the instance, an initialization parameter file is read. There are two types of parameter files. Server parameter file (SPFILE): This is the preferred type of initialization parameter file. It is a binary file that can be written to and read by the database server and must not be edited manually . It resides on the server on which the Oracle instance is executing; it is persistent across shutdown and startup. The default name of this file, which is automatically sought at startup, is spfile<SID>.ora . Text initialization parameter file: This type of initialization parameter file can be read by the database server, but it is not written to by the server. The initialization parameter settings must be set and changed manually by using a text editor so that they are persistent across shutdown and startup. The default name of this file (which is automatically sought at startup if an SPFILE is not found) is init<SID>.ora . It is recommended that you create an SPFILE as a dynamic way to maintain initialization parameters. Note: The Oracle database searches the $ORACLE_HOME/dbs directory on Linux for the initialization files. With ASM, the SPFILE is often located into an ASM disk group. In this case, an init<SID>.ora file should exist in the $ORACLE_HOME/dbs directory that identifies the SPFILE location.
• #14: Initialization Parameter Files (continued) Types of Values for Initialization Parameters The Oracle database server has the following types of values for initialization parameters: Boolean String Integer Parameter file Reserved Big Integer Derived Parameter Values Some initialization parameters are derived, meaning that their values are calculated from the values of other parameters. Normally, you should not alter values for derived parameters. But if you do, the value that you specify overrides the calculated value. For example, the default value of the SESSIONS parameter is derived from the value of the PROCESSES parameter. If the value of PROCESSES changes, the default value of SESSIONS changes as well unless you override it with a specified value. Operating System – Dependent Parameter Values The valid values or value ranges of some initialization parameters depend on the host operating system. For example, the DB_FILE_MULTIBLOCK_READ_COUNT parameter specifies the maximum number of blocks that are read in one I/O operation during a sequential scan; this parameter is platform dependent. The size of those blocks, which is set by DB_BLOCK_SIZE , has a default value that depends on the operating system. Setting Parameter Values Initialization parameters offer the most potential for improving system performance. Some parameters set capacity limits but do not affect performance. For example, when the value of OPEN_CURSORS is 10 , a user process attempting to open its eleventh cursor receives an error. Other parameters affect performance but do not impose absolute limits. For example, reducing the value of OPEN_CURSORS does not prevent work even though it may slow the performance. Increasing the values of parameters may improve your system’s performance, but increasing most parameters also increases the system global area (SGA) size. A larger SGA can improve database performance up to a point. In virtual memory operating systems, an SGA that is too large can degrade performance if it is swapped in and out of memory. Operating system parameters that control virtual memory working areas should be set with the SGA size in mind. The operating system configuration can also limit the maximum size of the SGA.
• #15: Oracle Database 11 g : Administration Workshop I 4 - Simplified Initialization Parameters Initialization parameters are of two types: basic and advanced. In the majority of cases, it is necessary to set and tune only the 30 basic parameters to get reasonable performance from the database. In rare situations, modification of the advanced parameters may be needed to achieve optimal performance. There are about 314 advanced parameters. A basic parameter is defined as one that you are likely to set to keep your database running with good performance. All other parameters are considered to be advanced. Examples of basic parameters: Determining the global database name: DB_NAME and DB_DOMAIN Specifying a fast recovery area and size: DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE Specifying the total size of all SGA components: SGA_TARGET Specifying the method of undo space management tablespace: UNDO_TABLESPACE COMPATIBLE initialization parameter and irreversible compatibility Note: Some of the initialization parameters are listed on the following pages. For a complete list, see the Oracle Database Reference .
• #16: Oracle Database 11 g : Administration Workshop I 4 - Initialization Parameters: Examples CONTROL_FILES parameter: Specifies one or more control file names. Oracle strongly recommends that you multiplex and mirror control files. Range of values: from one to eight file names (with path names). Default value: OS dependent. DB_FILES parameter: Specifies the maximum number of database files that can be opened for this database. Range of values: OS dependent. Default value: 200. PROCESSES parameter: Specifies the maximum number of OS user processes that can simultaneously connect to an Oracle server. This value should allow for all background processes and user processes. Range of values: from 6 to an OS-dependent value. Default value: 100. DB_BLOCK_SIZE parameter: Specifies the size (in bytes) of an Oracle database block. This value is set at database creation and cannot be subsequently changed. This specifies the standard block size for the database. All tablespaces will use this size by default. Range of values: 2048 to 32768 (OS dependent). Default value: 8192 . DB_CACHE_SIZE parameter: Specifies the size of the standard block buffer cache. Range of values: at least 16 MB. Default value: 0 if SGA_TARGET is set, otherwise the larger of 48 MB or (4 MB* cpu_count) .
• #17: Initialization Parameters: Examples (continued) SGA_TARGET specifies the total size of all SGA components. If SGA_TARGET is specified, the following memory pools are automatically sized: Buffer cache ( DB_CACHE_SIZE ) Shared pool ( SHARED_POOL_SIZE ) Large pool ( LARGE_POOL_SIZE ) Java pool ( JAVA_POOL_SIZE ) Streams pool ( STREAMS_POOL_SIZE ) If these automatically tuned memory pools are set to nonzero values, the values are used as minimum levels by Automatic Shared Memory Management (ASMM). You set minimum values if an application component needs a minimum amount of memory to function properly. The following pools are manually sized components and are not affected by ASMM: Log buffer Other buffer caches (such as KEEP and RECYCLE ) and other block sizes Fixed SGA and other internal allocations The memory allocated to these pools is deducted from the total available memory for SGA_TARGET when ASMM is enabled. Note: The MMON process computes the values of the automatically tuned memory pools to support ASMM.
• #18: Initialization Parameters: Examples (continued) MEMORY_TARGET specifies the Oracle systemwide usable memory. The database tunes memory to the MEMORY_TARGET value, reducing or enlarging the SGA and PGA as needed. In a text-based initialization parameter file, if you omit MEMORY_MAX_TARGET and include a value for MEMORY_TARGET , the database automatically sets MEMORY_MAX_TARGET to the value of MEMORY_TARGET . If you omit the line for MEMORY_TARGET and include a value for MEMORY_MAX_TARGET , the MEMORY_TARGET parameter defaults to zero. After startup, you can then dynamically change MEMORY_TARGET to a nonzero value if it does not exceed the value of MEMORY_MAX_TARGET . The MEMORY_TARGET parameter is modifiable with the ALTER SYSTEM command . Values range from 152 MB to MEMORY_MAX_TARGET .
• #19: Initialization Parameters: Examples (continued) PGA_AGGREGATE_TARGET parameter: Specifies the amount of Program Global Area (PGA) memory allocated to all server processes attached to the instance. This memory does not reside in the System Global Area (SGA). The database uses this parameter as a target amount of PGA memory to use. When setting this parameter, subtract the SGA from the total memory on the system that is available to the Oracle instance. The range of values comprises integers plus the letters K , M , or G (to specify this limit in kilobytes, megabytes, or gigabytes). The minimum value is 10 MB and the maximum value is (4096 GB – 1). The default is 10 MB or 20% of the size of the SGA, whichever is greater. SHARED_POOL_SIZE parameter: Specifies the size of the shared pool in bytes. The shared pool contains objects such as shared cursors, stored procedures, control structures, and parallel execution message buffers. Range of values: OS dependent. Default value: 0 if SGA_TARGET is set, otherwise 128 MB if 64 bit; 48 MB if 32 bit. UNDO_MANAGEMENT parameter: Specifies the undo space management mode that the system should use. When set to AUTO , the instance is started in Automatic Undo Management (AUM) mode. Otherwise, it is started in Rollback Undo (RBU) mode. In RBU mode, undo space is allocated externally as rollback segments. In AUM mode, undo space is allocated externally as undo tablespaces. Range of values: AUTO or MANUAL . If the UNDO_MANAGEMENT parameter is omitted when the first instance is started, the default value AUTO is used.
• #20: Using SQL*Plus to View Parameters The slide shows examples of using SQL*Plus to view parameters. You can query the data V$PARAMETER dictionary view to find the values of the various parameters. V$PARAMETER displays the current parameter values in the current session. You can also use the SHOW PARAMETER command with any string to view parameters that contain that string. The query in the following example is requesting the name and values of the parameters. Use a WHERE clause to specify specific parameter names: SQL> SELECT name, value FROM V$PARAMETER WHERE name LIKE '%pool%'; NAME VALUE ------------------------- ---------- shared_pool_size 0 large_pool_size 0 java_pool_size 0 streams_pool_size 0 shared_pool_reserved_size 8808038 buffer_pool_keep … 9 rows selected.
• #21: Using SQL*Plus to View Parameters (continued) Description of the view: SQL> desc V$parameter Name Null? Type ---------------------------------------- ------- ------------- NUM NUMBER NAME VARCHAR2(80) TYPE NUMBER VALUE VARCHAR2(4000) DISPLAY_VALUE VARCHAR2(4000) ISDEFAULT VARCHAR2(9) ISSES_MODIFIABLE VARCHAR2(5) ISSYS_MODIFIABLE VARCHAR2(9) ISINSTANCE_MODIFIABLE VARCHAR2(5) ISMODIFIED VARCHAR2(10) ISADJUSTED VARCHAR2(5) ISDEPRECATED VARCHAR2(5) ISBASIC VARCHAR2(5) DESCRIPTION VARCHAR2(255) UPDATE_COMMENT VARCHAR2(255) HASH NUMBER The second example shows the use of the SQL*Plus SHOW PARAMETER command to view parameter settings. You can also use this command to find all parameters that contain a text string. For example, you can find all parameter names that include the string db by using the following command: SQL> show parameter db NAME TYPE VALUE ------------------------------------ ----------- ---------- … db_8k_cache_size big integer 0 db_block_buffers integer 0 db_block_checking string FALSE db_block_checksum string TYPICAL db_block_size integer 8192 db_cache_advice string ON db_cache_size big integer 0 … Other Views Containing Information About Parameters V$SPPARAMETER : Displays information about the contents of the server parameter file. If a server parameter file was not used to start the instance, each row of the view will contain FALSE in the ISSPECIFIED column. V$PARAMETER2 : Displays information about the initialization parameters that are currently in effect for the session, with each parameter value appearing as a row in the view. A new session inherits parameter values from the instance-wide values displayed in the V$SYSTEM_PARAMETER2 view. V$SYSTEM_PARAMETER : Displays information about the initialization parameters that are currently in effect for the instance.
• #22: Changing Initialization Parameter Values There are two types of initialization parameters. Static parameters: Affect the instance or entire database and can be modified only by changing the contents of the init.ora or the SPFILE. Static parameters require the database to be shut down and restarted to take effect. They cannot be changed for the current instance. Dynamic parameters: Can be changed while database is online. There are two types: Session-level parameters affect only a user session. Examples include national language support (NLS) parameters that can be used to specify national language settings for sorts, date parameters, and so on. You can use these in a given session; they expire when the session ends. System-level parameters affect the entire database and all sessions. Examples include modifying the SGA_TARGET value and setting archive log destinations. These parameters stay in effect based on the SCOPE specification. To make them permanent, you have to add these parameter settings to the SPFILE by specifying the SCOPE=both option or manually editing the PFILE. Dynamic parameters can be changed by using the ALTER SESSION and ALTER SYSTEM commands.
• #23: Changing Initialization Parameter Values (continued) Use the SET clause of the ALTER SYSTEM statement to set or change initialization parameter values. The optional SCOPE clause specifies the scope of a change as follows: SCOPE=SPFILE : The change is applied in the server parameter file only. No change is made to the current instance. For both dynamic and static parameters, the change is effective at the next startup and is persistent. This is the only SCOPE specification allowed for static parameters. SCOPE=MEMORY : The change is applied in memory only. The change is made to the current instance and is effective immediately. For dynamic parameters, the effect is immediate but not persistent because the server parameter file is not updated. For static parameters, this specification is not allowed. SCOPE=BOTH : The change is applied in both the server parameter file and memory. The change is made to the current instance and is effective immediately. For dynamic parameters, the effect is persistent because the server parameter file is updated. For static parameters, this specification is not allowed. It is an error to specify SCOPE=SPFILE or SCOPE=BOTH if the instance did not start up with a server parameter file. The default is SCOPE=BOTH if a server parameter file was used to start up the instance, and the default is MEMORY if a text initialization parameter file was used to start up the instance. For some dynamic parameters, you can also specify the DEFERRED keyword. When it is specified, the change is effective only for future sessions. This is only valid for the following parameters: backup_tape_io_slaves recyclebin audit_file_dest object_cache_optimal_size object_cache_max_size_percent sort_area_size sort_area_retained_size olap_page_pool_size When you specify SCOPE as SPFILE or as BOTH , an optional COMMENT clause lets you associate a text string with the parameter update. The comment is written to the server parameter file.
• #24: Changing Parameter Values: Examples The first statement in the slide is an example of changing a session-level parameter. The user is setting the session date format to be mon dd yyyy . As a result, any queries on the date will display dates in that format. Session-level parameters can also be set in applications by using PL/SQL. The second statement changes the maximum number of failed login attempts before the connection is dropped. It includes a comment and explicitly states that the change is to be made only in the server parameter file. After the specified number of failure attempts, the connection is automatically dropped by the server process. This is not a dynamic parameter and the Oracle database instance will need to be restarted before the change can take effect.
• #25: Answer: 2
• #26: Answer: 1
• #27: Oracle Database 11 g : Administration Workshop I 4 - Database Startup and Shutdown: Credentials When you click either Startup or Shutdown, you are prompted for credentials that are used for both logging on to the host (the computer on which the database resides) and logging in to the database itself. You must enter a database account that has the SYSDBA privilege. Enter the credentials. After the credentials information, you will then be prompted for the method of startup or shutdown. You can then click Advanced Options to change any startup options or shutdown mode as needed. You can also click Show SQL to see the SQL statements that are used for startup or shutdown. Note: The default option to shut down by using Enterprise Manager is IMMEDIATE . The default when issuing the SHUTDOWN command from SQL*Plus is NORMAL .
• #28: Oracle Database 11 g : Administration Workshop I 4 - Starting Up an Oracle Database Instance If the database is currently not started when you go to the Enterprise Manager Database Control page, click Startup. Then enter the host credentials and, optionally, choose the startup mode. If the Oracle database has been registered with Oracle Restart, a separate dialog will prompt you with the choice of using the Server Control ( SRVCTL ) utility or SQL*Plus to start the database instance. The SRVCTL utility is the recommended utility when using Oracle Restart because it has the ability to start up dependent resources that may be needed.
• #29: Oracle Database 11 g : Administration Workshop I 4 - Starting Up an Oracle Database Instance: NOMOUNT When starting the database instance, select the state in which it starts. The following scenarios describe different stages of starting up an instance. An instance is typically started only in NOMOUNT mode during database creation, during re-creation of control files, or during certain backup and recovery scenarios. Starting an instance includes the following tasks: Searching $ORACLE_HOME/dbs for a file of a particular name in this sequence: 1. Search for spfile<SID>.ora . 2. If spfile<SID>.ora is not found, search for spfile.ora . 3. If spfile.ora is not found, search for init<SID>.ora . This is the file that contains initialization parameters for the instance. Specifying the PFILE parameter with STARTUP overrides the default behavior. Allocating the SGA Starting the background processes Opening the alert_<SID>.log file and the trace files Note: SID is the system ID, which identifies the instance name (for example, ORCL ).
• #30: Oracle Database 11 g : Administration Workshop I 4 - Starting Up an Oracle Database Instance: MOUNT Mounting a database includes the following tasks: Associating a database with a previously started instance Locating and opening all of the control files specified in the parameter file Reading the control files to obtain the names and statuses of the data files and online redo log files (However, no checks are performed to verify the existence of the data files and online redo log files at this time.) To perform specific maintenance operations, start an instance and mount a database, but do not open the database. For example, the database must be mounted but must not be opened during the following tasks: Renaming data files (Data files for an offline tablespace can be renamed when the database is open.) Enabling and disabling online redo log file archiving options Performing full database recovery Note: A database may be left in MOUNT mode even though an OPEN request has been made. This may be because the database needs to be recovered in some way. If recovery is performed while in the MOUNT state, the redo logs are open for reads and the data files are open as well to read the blocks needing recovery and to write blocks if required during recovery.
• #31: Oracle Database 11 g : Administration Workshop I 4 - Starting Up an Oracle Database Instance: OPEN A normal database operation means that an instance is started and the database is mounted and opened. With a normal database operation, any valid user can connect to the database and perform typical data access operations. Opening the database includes the following tasks: Opening the data files Opening the online redo log files If any of the data files or online redo log files are not present when you attempt to open the database, the Oracle server returns an error. During this final stage, the Oracle server verifies that all data files and online redo log files can be opened, and checks the consistency of the database. If necessary, the System Monitor (SMON) background process initiates instance recovery. You can start up a database instance in restricted mode so that it is available to users with administrative privileges only. To start an instance in restricted mode, select the “Restrict access to database” option on the Advanced Startup Options page.
• #32: Oracle Database 11 g : Administration Workshop I 4 - Startup Options: Examples The slide shows the SQL*Plus syntax to start up the database. 1. This command starts the instance, associates the database files to it, and mounts and opens the database 2. This command starts the instance and the database is not mounted 3. This command mounts a database from the NOMOUNT state. This command opens the database from the MOUNT state. When the database is enabled with Oracle Restart, the srvctl utility can be used to start the database instance. The srvctl utility has the advantage that it can also start all required dependent resources such as the ASM instance, ASM disk groups, and listener. Note: The srvctl utility is located in both the $ORACLE_HOME/bin directory for the Grid infrastructure software and the $ORACLE_HOME/bin directory for the Oracle database software. You should use the srvctl utility from the Oracle database software when starting the Oracle database. You should use the srvctl utility from the Grid Infrastructure software when starting the ASM Instance or the listener.
• #33: Oracle Database 11 g : Administration Workshop I 4 - Shutting Down an Oracle Database Instance If the instance is already started when you go to the Enterprise Manager Database Control page, click the Shutdown button to shut down the instance. You will be prompted to verify or enter the host and database credentials. Click OK to receive the Startup/Shutdown confirmation dialog. If you then click the Advanced Options button, you can select the mode of the shutdown: NORMAL , TRANSACTIONAL , IMMEDIATE , or ABORT .
• #34: Oracle Database 11 g : Administration Workshop I 4 - Shutdown Modes Shutdown modes are progressively more accommodating of current activity in this order: ABORT : Performs the least amount of work before shutting down. Because this mode requires recovery before startup, use it only when necessary. It is typically used when no other form of shutdown works, when there are problems when starting the instance, or when you need to shut down immediately because of an impending situation (such as notice of a power outage within seconds). IMMEDIATE : Is the most typically used option. Uncommitted transactions are rolled back. TRANSACTIONAL : Allows existing transactions to finish, but not starting new transactions NORMAL : Waits for sessions to disconnect If you consider the amount of time that it takes to perform the shutdown, you find that ABORT is the fastest and NORMAL is the slowest. NORMAL and TRANSACTIONAL can take a long time depending on the number of sessions and transactions.
• #35: Oracle Database 11 g : Administration Workshop I 4 - Shutdown Options SHUTDOWN NORMAL NORMAL is the default shutdown mode if no mode is specified. A normal database shutdown proceeds with the following conditions: No new connections can be made. The Oracle server waits for all users to disconnect before completing the shutdown. Database and redo buffers are written to disk. Background processes are terminated and the SGA is removed from memory. The Oracle server closes and dismounts the database before shutting down the instance. The next startup does not require an instance recovery. SHUTDOWN TRANSACTIONAL A shutdown in TRANSACTIONAL mode prevents clients from losing data, including results from their current activity. A transactional database shutdown proceeds with the following conditions: No client can start a new transaction on this particular instance. A client is disconnected when the client ends the transaction that is in progress. When all transactions have been completed, a shutdown occurs immediately. The next startup does not require an instance recovery.
• #36: Shutdown Options (continued) SHUTDOWN IMMEDIATE A shutdown in IMMEDIATE mode proceeds with the following conditions: Current SQL statements being processed by the Oracle database are not completed. The Oracle server does not wait for the users who are currently connected to the database to disconnect. The Oracle server rolls back active transactions and disconnects all connected users. The Oracle server closes and dismounts the database before shutting down the instance. The next startup does not require an instance recovery. Note: IMMEDIATE is the default shutdown mode when using Enterprise Manager.
• #37: Oracle Database 11 g : Administration Workshop I 4 - Shutdown Options (continued) SHUTDOWN ABORT If shutdown in NORMAL , TRANSACTIONAL , and IMMEDIATE modes does not work, you can abort the current database instance. Aborting an instance proceeds with the following conditions: Current SQL statements being processed by the Oracle server are immediately terminated. The Oracle server does not wait for users who are currently connected to the database to disconnect. Database and redo buffers are not written to disk. Uncommitted transactions are not rolled back. The instance is terminated without closing the files. The database is not closed or dismounted. The next startup requires instance recovery, which occurs automatically. Note: It is not advisable to back up a database that is in an inconsistent state.
• #38: Oracle Database 11 g : Administration Workshop I 4 - Shutdown Options: Examples The slide shows examples using both SQL*Plus and the SRVCTL utility to shut down the database. 1. This command initiates a normal shutdown. The database will not shutdown until all users have logged out. 2. This command initiates a transactional shutdown. The database will not shutdown until all existing transactions completed. 3. This command initiates an immediate shutdown. The uncommitted transactions will be rolled back 4. This command initiates a shutdown abort. When the database is enabled with Oracle Restart, the SRVCTL utility can be used to shutdown the database instance. Note: The SRVCTL utility is located in both the $ORACLE_HOME/bin directory for the Grid infrastructure software and the $ORACLE_HOME/bin directory for the Oracle database software. You should use the SRVCTL utility from the Oracle database software when starting the Oracle database. You should use the SRVCTL utility from the Grid Infrastructure software when starting the ASM Instance or the listener.
• #39: Oracle Database 11 g : Administration Workshop I 4 - Viewing the Alert Log Each database has an alert_< sid> .log file. The file is on the server with the database and is stored in $ORACLE_BASE/diag/rdbms/<db_name>/<SID>/trace by default if $ORACLE_BASE is set. The alert file of a database is a chronological log of messages such as the following: Any nondefault initialization parameters used at startup All internal errors ( ORA-600 ), block corruption errors ( ORA-1578 ), and deadlock errors ( ORA-60 ) that occurred Administrative operations, such as the SQL statements CREATE , ALTER , DROP DATABASE , and TABLESPACE , and the Enterprise Manager or SQL*Plus statements STARTUP , SHUTDOWN , ARCHIVE LOG , and RECOVER Several messages and errors relating to the functions of shared server and dispatcher processes Errors during the automatic refresh of a materialized view Oracle Database uses the alert log to keep a record of these events as an alternative to displaying the information on an operator’s console. (Many systems also display this information on the console.) If an administrative operation is successful, a message is written in the alert log as “completed” along with a time stamp.
• #40: Viewing the Alert Log (continued) Enterprise Manager monitors the alert log file and notifies you of critical errors. You can also view the log to see noncritical error and information messages. Because the file can grow to an unmanageable size, you can periodically back up the alert file and delete the current alert file. When the database attempts to write to the alert file again, it re-creates a new one. Note: There is an XML version of the alert log in the $ ORACLE_BASE/diag/rdbms/<db_name>/<SID>/alert directory. To determine the location of the alert log with SQL*Plus: Connect to the database with SQL*Plus (or another query tool such as SQL Developer). Query the V$DIAG_INFO view. To view the text-only alert log without the XML tags: In the V$DIAG_INFO query results, note the path that corresponds to the Diag Trace entry. Change directory to that path. Open the alert_SID.log file with a text editor. To view the XML-formatted alert log: In the V$DIAG_INFO query results, note the path that corresponds to the Diag Alert entry. Change directory to that path. Open the log.xml file with a text editor.
• #41: Using Trace Files Each server and background process can write to an associated trace file. When a process detects an internal error, it dumps information about the error to its trace file. If an internal error occurs and information is written to a trace file, the administrator should contact Oracle Support Services. All file names of trace files associated with a background process contain the name of the process that generated the trace file. The one exception to this is trace files that are generated by job queue processes ( Jnnn ). Additional information in trace files can provide guidance for tuning applications or an instance. Background processes always write this information to a trace file when appropriate. Beginning with Oracle Database 11 g , an advanced fault diagnosability infrastructure is included for preventing, detecting, diagnosing, and resolving problems. In particular, problems that are targeted include critical errors such as those caused by database code bugs, metadata corruption, and customer data corruption.
• #42: Using Trace Files (continued) When a critical error occurs, an incident number is assigned to it; diagnostic data for the error (such as trace files) is immediately captured and tagged with this number. The data is then stored in the automatic diagnostic repository (ADR)—a file-based repository outside the database—where it can later be retrieved by incident number and analyzed. The ADR is a systemwide tracing and logging central repository for database diagnostic data such as traces, the alert log, health monitor reports, and more. The ADR root directory is known as ADR base . Its location is set by the DIAGNOSTIC_DEST initialization parameter. If this parameter is omitted or left null, the database sets DIAGNOSTIC_DEST upon startup as follows: If the ORACLE_BASE environment variable is set, DIAGNOSTIC_DEST is set to the directory designated by ORACLE_BASE . If the ORACLE_BASE environment variable is not set, DIAGNOSTIC_DEST is set to ORACLE_HOME/log . The location of an ADR home is given by the following path, which starts at the ADR base directory: ./diag/product_type/db_id/instance_id
• #43: Oracle Database 11 g : Administration Workshop I 4 - Dynamic Performance Views The Oracle database also maintains a more dynamic set of data about the operation and performance of the database instance. These dynamic performance views are based on virtual tables that are built from memory structures inside the database server. That is, they are not conventional tables that reside in a database. This is the reason why some of them are available before a database is mounted or open. Dynamic performance views include information about: Sessions File states Progress of jobs and tasks Locks Backup status Memory usage and allocation System and session parameters SQL execution Statistics and metrics Note: The DICT and DICT_COLUMNS views also contain the names of these dynamic performance views. Dynamic performance views start with the prefix 'v$' and there are over 590 of them.
• #44: Oracle Database 11 g : Administration Workshop I 4 - Dynamic Performance Views: Usage Examples A frequent user of these views is Enterprise Manager, but users can also query these views as needed. The three examples shown in the slide answer the following questions: 1. For which SQL statements (and their associated numbers of executions) is the CPU time consumed greater than 200,000 microseconds? 2. Which current sessions are logged in from the EDRSR9P1 computer on the last day? 3. What are the session IDs of those sessions that are currently holding a lock that is blocking another user, and how long have those locks been held?
• #45: Oracle Database 11 g : Administration Workshop I 4 - Dynamic Performance Views: Considerations Some dynamic views contain data that is not applicable to all states of an instance or database. For example, if an instance has just been started but no database is mounted, you can query V$BGPROCESS to see the list of background processes that are running. But you cannot query V$DATAFILE to see the status of database data files because it is the mounting of a database that reads the control file to find out about the data files associated with a database. Some V$ views contain information that is similar to information in the corresponding DBA_ views. For example, V$DATAFILE is similar to DBA_DATA_FILES . Note also that V$ view names are generally singular and DBA_ view names are plural.
• #46: Oracle Database 11 g : Administration Workshop I 4 - Data Dictionary: Overview The Oracle data dictionary is the metadata of the database and contains the names and attributes of all objects in the database. The creation or modification of any object causes an update to the data dictionary that reflects those changes. This information is stored in the base tables that are maintained by the Oracle database, but you access these tables by using predefined views rather than reading the tables directly. The data dictionary: Is used by the Oracle database server to find information about users, objects, constraints, and storage Is maintained by the Oracle database server as object structures or definitions are modified Is available for use by any user to query information about the database Is owned by the SYS user Should never be modified directly using SQL Note: The DICTIONARY data dictionary view (or the DICT synonym for this) contains the names and descriptions of data dictionary tables and views. Use the DICT_COLUMNS view to see the view columns and their definitions. For complete definitions of each view, see the Oracle Database Reference . There are over 1000 views that reference hundreds of base tables.
• #47: Oracle Database 11 g : Administration Workshop I 4 - Data Dictionary Views The view prefixes indicate the data (and how much of that data) a given user can see. The global view of everything is accessed only by users with DBA privileges, using the DBA_ prefix. The next level of privilege is at the ALL_ prefix level, which represents all objects that the querying user is privileged to see, whether the user owns them or not. For example, if USER_A has been granted access to a table owned by USER_B , then USER_A sees that table listed in any ALL_ view dealing with table names. The USER_ prefix represents the smallest scope of visibility. This type of view shows only those objects that the querying user owns (that is, those that are present in the user’s own schema). Generally, each view set is a subset of the higher-privileged view set, row-wise and column-wise. Not all views in a given view set have a corresponding view in the other view sets. This is dependent on the nature of the information in the view. For example, there is a DBA_LOCK view, but there is no ALL_LOCK view. This is because only a DBA would have interest in data about locks. Be sure to choose the appropriate view set to meet the need that you have. If you have the privilege to access the DBA views, you still may want to query only the USER version of the view because the results show information on objects that you own and you may not want other objects to be added to your result set.
• #48: Data Dictionary Views (continued) The DBA_ views can only be queried by users with the SYSDBA or SELECT ANY DICTIONARY privilege. Not all dictionary views start with the prefix DBA_ , ALL_ , and USER_ . The following views or synonyms to views are exceptions to this: AUDIT_ACTIONS CAT CHANGE_PROPAGATIONS CHANGE_PROPAGATION_SETS CHANGE_SETS CHANGE_SOURCES CHANGE_TABLES CLIENT_RESULT_CACHE_STATS$ CLU COLS COLUMN_PRIVILEGES DATABASE_COMPATIBLE_LEVEL DBMS_ALERT_INFO DBMS_LOCK_ALLOCATED DICT DICTIONARY DICT_COLUMNS DUAL GLOBAL_NAME IND INDEX_HISTOGRAM INDEX_STATS LOGSTDBY_UNSUPPORTED_TABLES NLS_DATABASE_PARAMETERS NLS_INSTANCE_PARAMETERS NLS_SESSION_PARAMETERS OBJ RECYCLEBIN RESOURCE_COST ROLE_ROLE_PRIVS ROLE_SYS_PRIVS ROLE_TAB_PRIVS SEQ SESSION_PRIVS SESSION_ROLES SM$VERSION SYN TABLE_PRIVILEGES TABS
• #49: Oracle Database 11 g : Administration Workshop I 4 - Data Dictionary: Usage Examples The example queries in the slide answer the following questions: 1. What are the names of the tables (along with the name of the tablespace where they reside) that have been created in your schema? 2. What is the significant information about the sequences in the database that you have access to? 3. What users in this database are currently able to log in? 4. What are the columns of the DBA_INDEXES view? This shows you what information you can view about all the indexes in the database. The following is a partial output of this command: SQL> DESCRIBE dba_indexes Name Null? Type --------------- -------- ------------- OWNER NOT NULL VARCHAR2(30) INDEX_NAME NOT NULL VARCHAR2(30) INDEX_TYPE VARCHAR2(27) TABLE_OWNER NOT NULL VARCHAR2(30) TABLE_NAME NOT NULL VARCHAR2(30)
• #50: Answer: 2
• #51: Answer: 3
• #52: Oracle Database 11 g : Administration Workshop I 4 -
• #53: Oracle Database 11 g : Administration Workshop I 4 -