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