Oracle-9: Unit - 9 (A) One Mark Questions
Oracle-9: Unit - 9 (A) One Mark Questions
Oracle-9: Unit - 9 (A) One Mark Questions
UNIT – 9
The database is open and ready for use after being created. Once the operating
system is shut down, or the database is shut down, it must be started before it can
be accessed.
STARTUP MOUNT This command starts the instance and mounts the
database, but leaves it closed.
The databases should be shut down before system shutdowns, before full backups
and any time system operations require it to be shut down.
You should alter the shutdown scripts to do a SHUTDOWN IMMEDIATE. This backs
out any uncommitted user transactions, logs them out and then shuts down the
database. If a normal SHUTDOWN is performed, the system politely waits for all
users to log off of Oracle . . . if Joe is on vacation and left his terminal up in a form,
you could have a long wait. The other shutdown, SHUTDOWN ABORT, should only be
used for emergencies as it stops the database just as it is, with operations pending or
not. A SHUTDOWN ABORT will require a recovery on startup.
No option means SHUTDOWN NORMAL. The database waits for all users to
disconnect, prohibits new connects, then closes and dismounts the database,
then shuts down the instance.
SHUTDOWN IMMEDIATE. Cancels current calls like a system interrupt, and
closes and dismounts the database, then shuts down the instance. PMON
gracefully shuts down the user processes. No instance recovery is required on
startup.
SHUTDOWN ABORT. This doesn’t wait for anything. It shuts the database
down now. Instance recovery will probably be required on startup. You
should escalate to this by trying the other shutdowns first.
SQL*Loader loads data from external files into tables of an Oracle database. It has a
powerful data parsing engine that puts little limitation on the format of the data in
the datafile. You can use SQL*Loader to do the following:
Load data across a network. This means that you can run the SQL*Loader
client on a different system from the one that is running the SQL*Loader
server.
Load data from multiple datafiles during the same load session.
Load data into multiple tables during the same load session.
Selectively load data (you can load records based on the records' values).
A typical SQL*Loader session takes as input a control file, which controls the
behavior of SQL*Loader, and one or more datafiles. The output of SQL*Loader is an
Oracle database (where the data is loaded), a log file, a bad file, and potentially, a
discard file
Control Files:
A control file contains information about the associated database that is required for
access by an instance, both at startup and during normal operation. Control file
information can be modified only by Oracle; no database administrator or user can
edit a control file.
The names and locations of associated datafiles and online redo log files
Tablespace information
Checkpoint information
The most crucial structure for recovery operations is the online redo log, which
consists of two or more preallocated files that store all changes made to the
database as they occur. Every instance of an Oracle database has an associated
online redo log to protect the database in case of an instance failure.
Data Files
Oracle creates a datafile for a tablespace by allocating the specified amount of disk
space plus the overhead required for the file header. When a datafile is created, the
operating system under which Oracle runs is responsible for clearing old information
and authorizations from a file before allocating it to Oracle. If the file is large, this
process can take a significant amount of time. The first tablespace in any database is
always the SYSTEM tablespace, so Oracle automatically allocates the first datafiles of
any database for the SYSTEM tablespace during database creation.
Use the Automatic Undo Management feature, which uses undo tablespaces
instead of rollback segments to hold undo data, or
Create locally managed tablespaces to hold the rollback segments.
If you are running the database in rollback undo mode, at least one rollback
segment (other than the SYSTEM rollback segment) must be online.
If you are running the database in Automatic Undo Management mode, at
least one UNDO tablespace must be online.
The Export utility to write data from an Oracle database into an operating system file
in binary format. This file is stored outside the database, and it can be read into
another Oracle database using the Import utility.
The Export utility provides a simple way for you to transfer data objects between
Oracle databases, even if they reside on platforms with different hardware and
software configurations.
All users can export in table mode and user mode. Users with
the EXP_FULL_DATABASE role (privileged users) can export in all modes.
For example,
exp test/test FULL=y FILE= expdat.dmp GRANTS=y INDEXES=y CONSISTENT=y
The Import utility reads the object definitions and table data from an Export dump
file. It inserts the data objects into an Oracle database.
The Import utility provides four modes of import.
Full
User (Owner)
Table
Tablespace
All users can import in table mode and user mode. Users with the
IMP_FULL_DATABASE role (privileged users) can import in all modes.
An Oracle server consists of an Oracle database and an Oracle server instance. Every
time a database is started, a system global area (SGA) is allocated and Oracle
background processes are started. The combination of the background processes
and memory buffers is called an Oracle instance.
An Oracle server uses memory structures and processes to manage and access the
database. All memory structures exist in the main memory of the computers that
constitute the database system. Processes are jobs that work in the memory of these
computers.
An Oracle server uses memory structures and processes to manage and access the
database. All memory structures exist in the main memory of the computers that
constitute the database system. Processes are jobs that work in the memory of these
computers.
The architectural features discussed in this section enable the Oracle server to
support:
An Oracle server has two general types of processes: user processes and Oracle
processes.
with the server process through the program interface, which is described in a later
section.
Server Processes
Oracle can be configured to vary the number of user processes for each server
process. In a dedicated server configuration, a server process handles requests for a
single user process. A shared server configurationlets many user processes share a
small number of server processes, minimizing the number of server processes and
maximizing the use of available system resources.
On some systems, the user and server processes are separate, while on others they
are combined into a single process. If a system uses the shared server or if the user
and server processes run on different machines, then the user and server processes
must be separate. Client/server systems separate the user and server processes and
run them on different machines.
Background Processes
Each Oracle instance can use several background processes. The names of these
processes are DBWn, LGWR, CKPT, SMON, PMON, ARCn, RECO, Jnnn, Dnnn, LMS,
and QMNn.
The database writer writes modified blocks from the database buffer cache to the
datafiles. Although one database writer process (DBW0) is sufficient for most
systems, you can configure additional processes (DBW1 through DBW9 and DBWa
through DBWj) to improve write performance for a system that modifies data
heavily. The initialization parameter DB_WRITER_PROCESSES specifies the number of
DBWn processes.
Because Oracle uses write-ahead logging, DBWn does not need to write blocks when
a transaction commits. Instead, DBWn is designed to perform batched writes with
high efficiency. In the most common case, DBWnwrites only when more data needs
to be read into the SGA and too few database buffers are free. The least recently
used data is written to the datafiles first. DBWn also performs writes for other
functions, such as checkpointing.
The log writer writes redo log entries to disk. Redo log entries are generated in the
redo log buffer of the SGA, and LGWR writes the redo log entries sequentially into
an online redo log. If the database has a multiplexed redo log, then LGWR writes the
redo log entries to a group of online redo log files.
Checkpoint (CKPT)
At specific times, all modified database buffers in the SGA are written to the datafiles
by DBWn. This event is called a checkpoint. The checkpoint process is responsible for
signaling DBWn at checkpoints and updating all the datafiles and control files of the
database to indicate the most recent checkpoint.
Archiver (ARCn)
The archiver copies the online redo log files to archival storage after a log switch has
occurred. Although a single ARCn process (ARC0) is sufficient for most systems, you
can specify up to 10 ARCn processes by using the dynamic initialization
parameter LOG_ARCHIVE_MAX_PROCESSES. If the workload becomes too great for
the current number of ARCn processes, then LGWR automatically starts another
Gaurav k sardhara Page 11
Oracle-9
Recoverer (RECO)
Job queue processes are used for batch processing. Job queue processes are
managed dynamically. This enables job queue clients to use more job queue
processes when required. The resources used by the new processes are released
when they are idle.
Dispatcher (Dnnn)
The Lock Manager Server process (LMS) is used for inter-instance locking in Real
Application Clusters.