Less04 instance

Editor's Notes

• #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 database server (which connects it to Oracle Enterprise Manager Grid Control) or the stand-alone Oracle Enterprise Manager Database Control. This is also referred to as Database Console. Each of these components must be explicitly 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. The first component to be started is the management interface. After this is activated, the management interface can be used to start the other components.
• #5: Starting and Stopping Database Control Oracle provides a stand-alone management console called Database Control 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, and from any one Database Control, you can manage only one database. Before using Database Control, ensure that a dbconsole process is started. To start the dbconsole process, use the following command: emctl start dbconsole To stop the dbconsole process, use the following command: emctl stop dbconsole To view the status of the dbconsole process, use the following command: 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. 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 Enterprise Manager When you install an Oracle database, Oracle Universal Installer also installs Oracle Enterprise Manager (Enterprise Manager). Its Web-based Database Control serves as the primary tool for managing your Oracle database. You can access online help from any of the pages to assist you with the task at hand. You can drill down into links in most situations, where there is more specific information to be had about the contents of a page. Although you may sometimes want to write and execute commands that you compose yourself, Enterprise Manager provides a graphical interface for doing almost any task that you would have 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.
• #7: Accessing Oracle Enterprise Manager Open your Web browser, and enter the following URL: http://host name:port number/em 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 the database installation. In the Connect As option, select either SYSDBA or SYSOPER to log in to the database with special database administration privileges. 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: 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, which are also referred to as tabs, you can access the Performance, Administration, and Maintenance 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: Using SQL*Plus and iSQL*Plus to Access Your Database In addition to Enterprise Manager, you can use other Oracle tools, such as SQL*Plus and iSQL*Plus, 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.
• #10: Using iSQL*Plus iSQL*Plus is a browser-based interface to an Oracle database. It is a component of the SQL*Plus product. iSQL*Plus has a server-side listener process that must be started before you can connect with a browser. To start this server process, use: isqlplusctl start After the server process is started, connect to it by entering the following URL in a browser: http://host name:port/isqlplus The port number that is used by iSQL*Plus is usually 5560 unless Oracle Universal Installer (OUI) detects that something is already using that port. Check $ORACLE_HOME/install/portlist.ini to find the port used by iSQL*Plus.
• #11: Setting Up iSQL*Plus for SYSDBA and SYSOPER Access When the iSQL*Plus Connection Role page appears, notice that the SYSOPER and SYSDBA roles require special setup and authentication for security reasons. To do this, you must set up a user in the Oracle Application Server Containers for J2EE (OC4J) user manager and grant access to the webDba role for the user. Do this by performing the following steps. Note that the JAVA_HOME OS environment variable must be set to $ORACLE_HOME/jdk. 1.Change to the correct directory: cd $ORACLE_HOME/oc4j/j2ee/isqlplus/ application-deployments/isqlplus 2.Run the JAZN shell: $JAVA_HOME/bin/java -Djava.security.properties= $ORACLE_HOME /oc4j/j2ee/home/config/jazn.security.props -jar $ORACLE_HOME/oc4j/j2ee/home/jazn.jar -user "iSQL*Plus DBA/admin" -password welcome -shell
• #12: Setting Up iSQL*Plus for SYSDBA and SYSOPER Access (continued) 3.Create a user, choosing a username and password: JAZN> adduser "iSQL*Plus DBA" username password 4.Grant the webDba role to the user: JAZN> grantrole webDba "iSQL*Plus DBA" username 5.Exit the JAZN shell: JAZN> exit
• #13: Using SQL*Plus You can use the command-line interface to SQL*Plus to write 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, perform the following steps: 1.Open a terminal window. 2.At the command-line prompt, enter the SQL*Plus command in the form: $ sqlplus /nolog 3.Enter connect followed by the user you want to connect as. 4.When prompted, enter the user’s password. SQL*Plus starts and connects to the default database.
• #14: 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.
• #15: 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
• #16: Initialization Parameter Files When you start the instance, an initialization parameter file is read. There are two types of parameter files: Server parameter file: 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 in the server that the Oracle database is executing on, and is persistent across shutdown and startup. This is often referred to as a server parameter file (SPFILE). 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 means of maintaining initialization parameters. By using an SPFILE, you can store and manage your initialization parameters persistently in a server-side disk file.
• #17: Simplified Initialization Parameters Initialization parameters are divided into two groups: basic and advanced. In the majority of cases, it is necessary to set and tune only the 32 basic parameters to get reasonable performance from the database. In rare situations, modification of the advanced parameters may be needed to achieve optimal performance. 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. The examples of basic parameters include “destinations” or directory names for specific types of files: AUDIT_FILE_DEST, BACKGROUND_DUMP_DEST, CORE_DUMP_DEST, DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and USER_DUMP_DEST. Initialization Parameters: Examples The CONTROL_FILES parameter specifies one or more control file names. Oracle strongly recommends that you multiplex and mirror control files. The range of values for this parameter is from 1 to 8 file names (with path names). The default range is OS dependent.
• #18: Simplified Initialization Parameters (continued) Initialization Parameters: Examples (continued) The 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. Range of values: 1024 – 65536 (OS dependent). Default value: 8K (OS dependent). The DB_CACHE_SIZE parameter specifies the size of the standard block buffer cache. Range of values: At least 16 MB. Default value: 48 MB. The DB_FILE_MULTIBLOCK_READ_COUNT parameter specifies the maximum number of blocks read during an input/output (I/O) operation involving a full sequential scan. Range of values: Operating system dependent. Default value: 8. The DB_FILES parameter specifies the maximum number of database files that can be opened for this database. Range of values: MAXDATAFILES – OS dependent. Default value: OS dependent (200 on Solaris). The PGA_AGGREGATE_TARGET parameter specifies the amount of Program Global Area (PGA) memory allocated to all server processes attached to the instance. Set this parameter to a positive value before enabling the automatic setting of working areas. 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 available to the Oracle instance. The remaining memory can be assigned to PGA_AGGREGATE_MEMORY. Range of values: Integers plus letter K, M, or G to specify this limit in kilobytes, megabytes, or gigabytes. Minimum value is 10M and maximum value is 400G. Default: “Not Specified,” which means that the automatic tuning of work areas is fully disabled. The 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. Range of values: 6 to an OS-dependent value. Default value: Depends on the PARALLEL_MAX_SERVERS parameter. The 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. Larger values can improve performance in multiuser systems. Range of values: 300 KB – OS dependent. Default value: If 64 bit, then 64 MB, or else 16 MB. The UNDO_MANAGEMENT parameter specifies which undo space management mode the system should use. When set to AUTO, the instance is started in System Managed Undo (SMU) mode. Otherwise, it is started in Rollback Undo (RBU) mode. In RBU mode, undo space is allocated externally as rollback segments. In SMU mode, undo space is allocated externally as undo tablespaces. Range of values: AUTO or MANUAL. Default value: If the UNDO_MANAGEMENT parameter is omitted when the first instance is started, the default value of MANUAL is used and the instance is started in RBU mode. If it is not the first instance, the instance is started in the same undo mode as all other existing instances.
• #19: Viewing and Modifying Initialization Parameters You can use Enterprise Manager to view and modify initialization parameters by clicking All Initialization Parameters in the Database Configuration region of the Database Administration tabbed page.
• #20: Database Startup and Shutdown 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. Enter the credentials. You can then click Advanced Options to change any startup options or shutdown mode, as needed. Also, you can click Show SQL to see the SQL statements that are used for the startup or shutdown.
• #21: 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 to perform the startup. Enter the host credentials and, optionally, choose the startup mode.
• #22: 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>/database for a file of a particular name in this order: spfile<SID>.ora If not found, spfile.ora If not found, 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 (for example, ORCL).
• #23: 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 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.
• #24: 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 online 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, then the Oracle server returns an error. During this final stage, the Oracle server verifies that all the 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.
• #25: Shutting Down an Oracle Database Instance If the instance is already started when you go to the Enterprise Manager Database Control page, you can click the Shutdown button to shut down the instance. If you then click the Advanced Options button, you can select the mode of the shutdown: Normal, Transactional, Immediate, or Abort.
• #26: 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 requires recovery before startup, use this only when necessary. This 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 transactions to finish 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.
• #27: SHUTDOWN Options SHUTDOWN NORMAL Normal is the default shutdown mode. 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 transactional shutdown prevents clients from losing data, including the 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.
• #28: SHUTDOWN Options (continued) SHUTDOWN IMMEDIATE Immediate database shutdown 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.
• #29: SHUTDOWN Options (continued) SHUTDOWN ABORT If the NORMAL and IMMEDIATE shutdown options do 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 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.
• #30: Using SQL*Plus to Start Up and Shut Down You can also use SQL*Plus to start up, shut down, and otherwise change the state of the database. To use SQL*Plus for these tasks, you must log in as SYSDBA or SYSOPER. Then, use the equivalent commands for the Enterprise Manager functionality discussed earlier: SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT ] STARTUP [FORCE] [RESTRICT] [MOUNT | OPEN | NOMOUNT] This enables you to include startup and shutdown operations as part of a script or batch process that performs tasks on the database, where the database needs to be in a particular state.
• #31: 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 the directory specified with the background_dump_dest initialization parameter. The alert file of a database is a chronological log of messages and errors, including 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 Enterprise Manager monitors the alert log file and notifies you of critical errors. You can also view the log to see noncritical error and informative messages. The file can grow to an unmanageable size. You can occasionally 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.
• #32: Viewing the Alert History The Alert History page displays a chart that shows the alert history of the current database in segments of time, which you designate. An alert indicates a potential problem: either a warning or critical threshold for a monitored metric, or that a target is no longer available.
• #33: 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 why some of them can show you data 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.
• #34: 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: a. What are the SQL statements and their associated number of executions where the CPU time consumed is greater than 200,000 microseconds? b. What sessions logged in from the EDRSR9P1 computer within the last day? c. What are the session IDs of any sessions that are currently holding a lock that is blocking another user, and how long has that lock been held?
• #35: 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.