OCA/OCP Oracle Database 11g All-in-One Exam Guide108 Describe the Stages of Database Startup and Shutdown Oracle Corporation’s recommended sequence for starting a database is to start D
Trang 1OCA/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
Trang 25 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;
Trang 3OCA/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
Trang 4In 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
Trang 5OCA/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
Trang 6Figure 3-4 Database Control, failing to detect any other Oracle processes
Figure 3-5 An example of the status of a running database listener
Trang 7OCA/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
Trang 8wish 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
Trang 9OCA/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
Trang 10Startup: 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