OCA/OCP Oracle Database 11g All-in-One Exam GOCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P16uide 106 Certain parameters affect the entire system, pptx

OCA/OCP Oracle Database 11g All-in-One Exam Guide 106 Certain parameters affect the entire system, individual sessions, or both. An example of a parameter that applies to the whole instance but can also be adjusted for individual sessions is OPTIMIZER_MODE. This influences the way in which Oracle will execute statements. A common choice is between the values ALL_ROWS and FIRST_ROWS. ALL_ROWS instructs the optimizer to generate execution plans that will run the statement to completion as quickly as possible, whereas FIRST_ROWS instructs it to generate plans that will get something back to the user as soon as possible, even if the complete execution of the statement ultimately takes longer to complete. So if your database is usually used for long DSS-type queries but some users use it for interactive work, you might issue the command alter system set optimizer_mode=all_rows; and let those individual users issue alter session set optimizer_mode=first_rows; There are a few parameters that can only be modified at the session level. Principal among these is NLS_DATE_FORMAT. This parameter, which controls the display of date and time values, can be specified in the parameter file but cannot be changed with ALTER SYSTEM. So it is static, as far as the instance is concerned. But it can be adjusted at the session level: alter session set nls_date_format='dd-mm-yy hh24:mi:ss'; This will change the current session’s date/time display to the European norm without affecting any other sessions. Exercise 3-1: Query and Set Initialization Parameters In this exercise, use either SQL*Plus or SQL Developer to manage initialization parameters. 1. Connect to the database (which must be open!) as user SYS, with the SYSDBA privilege. Use either operating system authentication or password file authentication. 2. Display all the basic parameters, checking whether they have all been set or are still on default: select name,value,isdefault from v$parameter where isbasic='TRUE' order by name; 3. Any basic parameters that are on default should be investigated to see if the default is appropriate. In fact, all the basic parameters should be considered. Read up on all of them in the Oracle documentation. The volume you need is titled Oracle Database Reference. Part 1, Chapter 1 has a paragraph describing every initialization parameter. 4. Change the PROCESSES parameter to 200. This is a static parameter which means its value cannot be changed in memory with immediate effect. It must be set in the static pfile, or if you are using an spfile, it can be set as described in the illustration by specifying “scope=spfile” and then restarting the database. Chapter 3: Instance Management 107 PART I 5. Rerun the query from Step 3. Note the new value for PROCESSES, and also for SESSIONS. PROCESSES limits the number of operating system processes that are allowed to connect to the instance, and SESSIONS limits the number of sessions. These figures are related, because each session will require a process. The default value for SESSIONS is derived from PROCESSES, so if SESSIONS was on default, it will now have a new value. 6. Change the value for the NLS_LANGUAGE parameter for your session. Choose whatever mainstream language you want (Oracle supports many languages: 67 at the time of writing), but the language must be specified in English (e.g., use “German,” not “Deutsch”): alter session set nls_language=German; 7. Confirm that the change has worked by querying the system date: select to_char(sysdate,'day') from dual; You may want to change your session language back to what it was before (such as English) with another ALTER SESSION command. If you don’t, be prepared for error messages to be in the language your session is now using. 8. Change the OPTIMIZER_MODE parameter, but restrict the scope to the running instance only; do not update the parameter file. This exercise enables the deprecated rule-based optimizer, which might be needed while testing some old code. alter system set optimizer_mode=rule scope=memory; 9. Confirm that the change has been effected, but not written to the parameter file: select value from v$parameter where name='optimizer_mode' union select value from v$spparameter where name='optimizer_mode'; 10. Return the OPTIMIZER_MODE to its standard value, in the running instance: alter system set optimizer_mode=all_rows scope=memory; OCA/OCP Oracle Database 11g All-in-One Exam Guide 108 Describe the Stages of Database Startup and Shutdown Oracle Corporation’s recommended sequence for starting a database is to start Database Control, then the database listener, and then the database. Starting the database is itself a staged process. There is no necessity to follow this sequence, and in more complex environments such as clustered systems or those managed by Enterprise Manager Grid Control there may well be additional processes too. But this sequence will suffice for a simple single-instance environment. Starting and Connecting to Database Control Database Control is a tool for managing one database (though this database can be clustered). If there are several database instances running off the same Oracle Home, each instance will have its own Database Control instance. The tool is written in Perl and Java, and accessed from a browser. There is no need to have a Java Runtime Environment or a Perl interpreter installed on the system; both are provided in the Oracle Home and installed by the OUI. All communications with Database Control are over HTTPS, the secure sockets variant of HTTP, and there should therefore be no problems with using Database Control from a browser anywhere in the world—the communications will be secure, and any firewall proxy servers will have no problem routing them. The only configuration needed on the firewall will be making it aware of the port on which Database Control is listening for connection requests. The configuration of Database Control is done at database creation time. This configuration includes two vital bits of information: the hostname of the computer on which Database Control is running, and the TCP port on which it will be listening. If it is ever necessary to change either of these, Database Control will need to be reconfigured. To start Database Control, use the emctl utility located in the ORACLE_HOME/bin directory. The three commands to start or stop Database Control and to check its status are emctl start dbconsole emctl stop dbconsole emctl status dbconsole For these commands to work, three environment variables must be set: PATH, ORACLE_HOME, and ORACLE_SID. PATH is needed to allow the operating system to find the emctl utility. The ORACLE_HOME and ORACLE_SID are needed so that emctl can find the Database Control configuration files. These are in three places: the directory ORACLE_HOME/sysman/config has general configuration directives that will apply to all Database Control instances running from the Oracle Home (one per database). The ORACLE_HOME/hostname_sid/sysman/config and a similarly named directory beneath ORACLE_HOME/oc4j/j2ee contain details for the Database Control that manages one particular database (hostname is the hostname of the machine, and sid is the value of the ORACLE_SID variable). Figure 3-3 shows the startup of Database Control, after a couple of problems. Chapter 3: Instance Management 109 PART I In Figure 3-3, the first attempt to query the status of Database Control fails because the ORACLE_SID environment variable is not set. Without this, the emctl utility can’t find the necessary configuration files. This is further demonstrated by setting the ORACLE_SID to a nonexistent instance name; the emctl status dbconsole command uses this environment variable to construct a directory path that does not exist. After setting the ORACLE_SID correctly, to ocp11g, the emctl executable is located and its status can be queried. The nature of this query is nothing more than accessing a URL; this URL can also be accessed from any browser as a simple test. As Database Control is not running, the example in the figure continues with starting it, and then again queries the status—this time successfully. Because this example is on a Windows system, the startup involves starting a Windows service, called OracleDBConsoleocp11g. To connect to Database Control using your web browser, navigate to the URL https://hostname:port/em where hostname is the name of the machine on which Database Control is running, and port is the TCP port on which it is listening for incoming connection requests. If the host has several names or several network interface cards, any will do. You can even use a loopback address, such as 127.0.0.1, because the Database Control process does listen on all addresses. To identify the port, you can use emctl. As shown in Figure 3-3, the output of emctl status dbconsole shows the port on which Database Control should be running. Alternatively, you can look in the file ORACLE_ HOME/install/portlist.ini, which lists all the ports configured by the OUI and DBCA. Figure 3-3 Database Control startup, on a Windows system OCA/OCP Oracle Database 11g All-in-One Exam Guide 110 As Database Control (the current version, not the one released with 10g) requires the use of HTTPS for security reasons, when you connect from your browser with the URL just given, you may (depending on your local security settings) receive a message regarding the digital certificate that Database Control is returning to your browser. This certificate was generated by Oracle when the Oracle Home was installed and the database created. Your browser performs three checks on the validity of the certificate. The first check is that the certificate is issued by a certificate issuing authority that your browser is prepared to trust. If you view the details of the certificate, you will see that the certificate was issued by the computer on which the Oracle installation was made. Presumably this is a trustworthy source, so that is not a problem. The second check is for the validity dates of the certificate. The third check is whether the host requested in the URL is the same as the host to which the certificate was issued. These will usually be the same, but if the machine has several hostname aliases or network interface cards, they may not be. TIP The mechanism for managing certificates and HTTPS will vary depending on your browser and how it is configured. For Database Control, the certificate really doesn’t matter; you do not need secure sockets for authentication, only for encryption. Once past any SSL certificate issue (which may not arise, depending on local security configuration), you will see the Database Control logon window, if the database listener is running. If the listener is not running, you will see the screen in Figure 3-4, which is presented when Database Control cannot detect the listener or the database instance. Starting the Database Listener The database listener is a process that monitors a port for database connection requests. These requests (and all subsequent traffic once a session is established) use Oracle Net, Oracle’s proprietary communications protocol. Oracle Net is a layered protocol running over whatever underlying network protocol is in use, usually TCP/IP. Managing the listener is fully described in Chapter 4, but it is necessary to know how to start it now. There are three ways to start the database listener: • With the lsnrctl utility • With Database Control • As a Windows service (Windows only, of course) The lsnrctl utility is located in the ORACLE_HOME/bin directory. The key commands are lsnrctl start [listener] lsnrctl status [listener] where listener is the name of listener. This will have defaulted to LISTENER, which is correct in most cases. You will know if you have created a listener with another name. Figure 3-5 shows the output of the lsnrctl status command when the listener is running. Chapter 3: Instance Management 111 PART I Figure 3-4 Database Control, failing to detect any other Oracle processes Figure 3-5 An example of the status of a running database listener OCA/OCP Oracle Database 11g All-in-One Exam Guide 112 Note the third line of the output in the figure shows the host address and port on which the listener is listening, and the fifth line from the bottom states that the listener will accept connections for a service “ocp11g”, which is offered by an instance called “ocp11g”. These are the critical bits of information needed to connect to the database. Following a successful database creation with DBCA, it can be assumed that they are correct. If the listener is not running, the output of lsnrctl status will make this very clear. Use lsnrctl start to start it, or click the START LISTENER Database Control button, shown in Figure 3-4. Starting SQL*Plus As discussed in previous chapters, this couldn’t be simpler. SQL*Plus is just an elementary client-server program used for issuing SQL commands to a database. A variation you need to be aware of is the NOLOG switch. By default, the SQL*Plus program immediately prompts you for an Oracle username, password, and database connect string. This is fine for regular end users, but useless for database administrators because it requires that the database must already be open. To launch SQL*Plus without a login prompt, use the /NOLOG switch: sqlplus /nolog This will give you a SQL prompt, from which you can connect with a variety of syntaxes, detailed in the next section. Many DBAs working on Windows will want to modify the Start menu shortcut to include the NOLOG switch. Database Startup and Shutdown If one is being precise (always a good idea, if you want to pass the OCP examinations), one does not start or stop a database: an instance may be started and stopped; a database is mounted and opened, and then dismounted and closed. This can be done from either SQL*Plus, using the STARTUP and SHUTDOWN commands, or through Database Control. On a Windows system, it may also be done by controlling the Windows service within which the instance runs. The alert log will give details of all such operations, however they were initiated. Startup and shutdown are critical operations. As such, they are always recorded and can only be carried out by highly privileged users. Connecting with an Appropriate Privilege Ordinary users cannot start up or shut down a database. This is because an ordinary user is authenticated against the data dictionary. It is logically impossible for an ordinary user to start up an instance and open (or create) a database, since the data dictionary cannot be read until the database is open. You must therefore connect with some form of external authentication: you must be authenticated either by the operating system, as being a member of the group that owns the Oracle software, or by giving a username/ password combination that exists in an external password file. You tell Oracle that you Chapter 3: Instance Management 113 PART I wish to use external authentication by using appropriate syntax in the CONNECT command that you submit in your user process. If you are using SQL*Plus, the syntax of the CONNECT command tells Oracle what type of authentication you wish to use: the default of data dictionary authentication, password file authentication, or operating system authentication. These are the possibilities after connecting using the /NOLOG switch as described previously: connect user/pwd[@connect_alias] connect user/pwd[@connect_alias] as sysdba connect user/pwd[@connect_alias] as sysoper connect / as sysdba connect / as sysoper In these examples, user is the username and pwd is the password. The connect_alias is a network identifier, fully described in Chapter 4. The first example is normal, data dictionary authentication. Oracle will validate the username/password combination against values stored in the data dictionary. The database must be open, or the connect will fail. Anyone connecting with this syntax cannot, no matter who they are, issue startup or shutdown commands. The second two examples instruct Oracle to go to the external password file to validate the username/password combination. The last two examples use operating system authentication; Oracle will go to the host operating system and check whether the operating system user running SQL*Plus is a member of the operating system group that owns the Oracle software, and if the user passes this test, they will be logged on as SYSDBA or SYSOPER without any need to provide a username and password. A user connecting with any of the bottom four syntaxes will be able to issue startup and shutdown commands and will be able to connect no matter what state the database is in—it may not even have been created yet. Note that the first three examples can include a network identifier string; this is necessary if the connection is to be made across a network. Naturally, this is not an option for operating system authentication, because operating system authentication relies on the user being logged on to the machine hosting the Oracle server: they must either be working on it directly or have logged in to it with telnet, secure shell, or some similar utility. TIP From an operating system prompt, you can save a bit of time and typing by combining the launch of SQL*Plus and the CONNECT into one command. Here are two examples: sqlplus / as sysdba sqlplus sys/oracle@orcl as sysdba Database Control will, by default, attempt to connect through a listener, but it can also use operating system authentication. If the situation is that depicted in Figure 3-4, clicking the STARTUP button will require operating system logon credentials to be entered in order to proceed. If the listener is running, Database Control will present the login window shown in Figure 3-6. The Connect As list of values lets you choose whether to make a normal connection or a SYSDBA connection. OCA/OCP Oracle Database 11g All-in-One Exam Guide 114 SYSOPER and SYSDBA These are privileges with special capabilities. They can only be enabled when users are connecting with an external authentication method: either operating system or password file. SYSOPER has the ability to issue these commands: STARTUP SHUTDOWN ALTER DATABASE [MOUNT | OPEN | CLOSE | DISMOUNT] ALTER [DATABASE | TABLESPACE] [BEGIN | END] BACKUP RECOVER The SYSDBA privilege includes all of these, but in addition has the ability to create a database, to perform incomplete recovery, and to create other SYSOPER and SYSDBA users. EXAM TIP SYSDBA and SYSOPER are not users; they are privileges that can be granted to users. By default, only user SYS has these privileges until they are deliberately granted to other users. You may be wondering what Oracle user you are actually logging on as when you use operating system authentication. To find out, from a SQL*Plus prompt connect using the operating system authentication syntax already shown, and then issue the show user command (which can be abbreviated to sho user—never underestimate the importance of saving keystrokes) as shown in the examples in Figure 3-7. Use of the SYSDBA privilege logs you on to the instance as user SYS, the most powerful user in the database and the owner of the data dictionary. Use of the SYSOPER privilege connects you as user PUBLIC. PUBLIC is not a user in any normal sense—it is a notional user with administration privileges, but (by default) has no privileges that lets it see or manipulate data. You should connect with either of these privileges only when you need to carry out procedures that no normal user can perform. Figure 3-6 The Database Control login window, when a listener has been detected Chapter 3: Instance Management 115 PART I Startup: NOMOUNT, MOUNT, and OPEN Remember that the instance and the database are separate entities that exist independently of each other. When an instance is stopped, no memory structures or background processes exist and the instance ceases to exist, but the database (consisting of files) endures. Indeed, in a RAC environment other instances on other nodes could exist and connect to the database. The startup process is therefore staged: first you build the instance in memory, second you enable a connection to the database by mounting it, and third you open the database for use. At any moment, a database will be in one of four states: • SHUTDOWN • NOMOUNT • MOUNT • OPEN When the database is SHUTDOWN, all files are closed and the instance does not exist. In NOMOUNT mode, the instance has been built in memory (the SGA has been created and the background processes started, according to whatever is specified in its parameter file), but no connection has been made to a database. It is indeed possible that the database does not yet exist. In MOUNT mode, the instance locates and reads the database control file. In OPEN mode, all database files are located and opened and the database is made available for use by end users. The startup process is staged: whenever you issue a startup command, it will go through these stages. It is possible to stop the startup partway. For example, if your control file is damaged, or a multiplexed copy is missing, you will not be able to mount the database, but by stopping in NOMOUNT mode you may be able to repair the damage. Similarly, if there are problems with any datafiles or redo logfiles, you may be able to repair them in MOUNT mode before transitioning the database to OPEN mode. Figure 3-7 Use of operating system and password file authentication . OCA/OCP Oracle Database 11g All-in-One Exam Guide 106 Certain parameters affect the entire system, individual sessions, or both. An example of a parameter that applies to the whole instance. optimizer_mode=all_rows scope=memory; OCA/OCP Oracle Database 11g All-in-One Exam Guide 108 Describe the Stages of Database Startup and Shutdown Oracle Corporation’s recommended sequence for starting a database. environment. Starting and Connecting to Database Control Database Control is a tool for managing one database (though this database can be clustered). If there are several database instances running off the