ORACLE ARCHITECTURE
Process management
Oracle Database creates server processes to handle the requests of user processes connected to an instance. A server process can be
a dedicated server process - services only one user process
a shared server process - can service multiple user processes
Dedicated server processes are always enabled but one or more initialization parameters must be set to configure and enable shared server
processes.
In a shared server configuration, client user processes connect to a dispatcher which can support multiple client connections concurrently.
Each client connection is bound to a virtual circuit which is a piece of shared memory used by the dispatcher for client database connection
requests and replies. The dispatcher places a virtual circuit on a common queue when a request arrives.
An idle shared server process picks up the virtual circuit from the common queue, services the request and relinquishes the virtual circuit
before attempting to retrieve another virtual circuit from the common queue. This approach enables a small pool of server processes to
serve a large number of clients. A significant advantage of shared server architecture over the dedicated server model is the reduction of
system resources, enabling the support of an increased number of users.
The following initialization parameters control shared server operation
SHARED_SERVERS - specifies the initial number of shared servers to start and the minimum number of shared servers to keep. This is the
only required parameter for using shared servers
MAX_SHARED_SERVERS - specifies the maximum number of shared servers that can run simultaneously
SHARED_SERVER_SESSIONS - specifies the total number of shared server user sessions that can run simultaneously and enables reserving
user sessions for dedicated servers
DISPATCHERS - configures dispatcher processes in the shared server architecture
MAX_DISPATCHERS - specifies the maximum number of dispatcher processes that can run simultaneously. This parameter can be ignored and
will only be useful in a future release when the number of dispatchers is auto-tuned according to the number of concurrent connections
CIRCUITS - specifies the total number of virtual circuits that are available for inbound and outbound network sessions
Physical storage structures
An Oracle database is a set of files that store Oracle data in persistent disk storage. The database files generated when a CREATE DATABASE
statement is issued are
Data files and temp files - a data file is a physical file on disk that contains data structures such as tables and indexes. A temp
file is a data file that belongs to a temporary tablespace
Control files - a control file is a root file that tracks the physical components of the database
Online redo log files - is a set of files containing records of changes made to data
A database instance is a set of memory structures that manage database files.
Logical storage structures
The logical units of database space allocation are data blocks, extents, segments and tablespaces.
A data block is the smallest logical unit of data storage that Oracle Database can use or allocate. One logical data block corresponds to a
specific number of bytes of physical disk space e.g 2 KB.
An extent is a set of logically contiguous data blocks allocated for storing a specific type of information
A segment is a set of extents allocated for a specific database object, such as a table. For e.g the data for the employees table is stored
in its own data segment, whereas each index for employees is stored in its own index segment. Every database object that consumes storage
consists of a single segment.
A tablespace is a database storage unit that contains one or more segments. Each segment belongs to one and only one tablespace. Thus, all
extents for a segment are stored in the same tablespace. Within a tablespace, a segment can include extents from multiple data files. For
e.g one extent for a segment may be stored in users01.dbf, while another is stored in users02.dbf. A single extent can never span data
files.
Logical Space Management
Oracle Database uses logical space management to track and allocate the extents in a tablespace. When a database object requires an extent,
the database finds and provides it. Similarly, when an object no longer requires an extent, the database makes the free extent available.
Oracle Database manages space within a tablespace in two ways:
Locally managed tablespaces (default) - The database uses bitmaps in the tablespaces themselves to manage extents i.e a part of the
tablespace is set aside for a bitmap. Within a tablespace, the database can manage segments with automatic (ASSM) or manual segment space
management (MSSM).
Dictionary-managed tablespaces - The database uses the data dictionary to manage extents.
Tablespaces
A database is divided into logical storage units called tablespaces, which group related logical structures together. A tablespace consists
of one or more datafiles that are explicitly created for each tablespace to physically store the data of all logical structures in the
tablespace. A datafile can be associated with only one tablespace and only one database. The combined size of the datafiles in a tablespace
is the total storage capacity of the tablespace.
A database's data is collectively stored in the datafiles that constitute each tablespace of the database. The simplest Oracle database
would have one tablespace and one datafile. A database can be enlarged in three ways:
add a datafile to a tablespace
add a new tablespace
increase the size of a datafile
Every Oracle database contains a SYSTEM tablespace and a SYSAUX tablespace.
The SYSTEM tablespace is used to manage the database and includes
the data dictionary
tables and views that contain administrative information about the database
compiled stored objects such as triggers, procedures, and packages
The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace and reduces the load on the SYSTEM tablespace.
select * from dba_tablespaces;
select * from dba_data_files; - data files and associated tablespaces
Locally managed tablespaces
A locally managed tablespace uses a bitmap stored in each data file to track all extent information in the tablespace itself. Locally
managed tablespaces provide the following benefits
Fast, concurrent space operations since space allocations and deallocations modify locally managed resources (bitmaps stored in header
files)
enhanced performance
readable standby databases are allowed because locally managed temporary tablespaces do not generate any undo or redo
space allocation is simplified, because when the AUTOALLOCATE clause is specified, the database automatically selects the appropriate
extent size
user reliance on the data dictionary is reduced as the necessary information is stored in file headers and bitmap blocks
coalescing free extents is unnecessary
CREATE TABLESPACE loctbsp DATAFILE '/u02/oracle/data/loctbsp01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
All tablespaces, including the SYSTEM tablespace, can be locally managed. The DBMS_SPACE_ADMIN package provides maintenance procedures for
locally managed tablespaces.
Bigfile Tablespaces
A bigfile tablespace is a tablespace with a single, potentially very large (up to 4G blocks) data file. Traditional smallfile tablespaces
can contain multiple data files, but the files cannot be as large. Bigfile tablespaces can increase the storage capacity of a database and
reduce the burden of managing many data files and temp files.
The benefits of bigfile tablespaces are:
A bigfile tablespace with 8K blocks can contain a 32 TB data file. A bigfile tablespace with 32K blocks can contain a 128 TB data file. The
maximum number of data files in an Oracle Database is limited (usually to 64K files), so bigfile tablespaces can significantly enhance
the storage capacity of the database.
Bigfile tablespaces can reduce the number of data files needed for a database. An additional benefit is that the DB_FILES initialization
parameter and MAXDATAFILES parameter of the CREATE DATABASE and CREATE CONTROLFILE statements can be adjusted to reduce the amount of SGA
space required for data file information and the size of the control file.
Bigfile tablespaces simplify database management by providing data file transparency. The ALTER TABLESPACE statement performs operations
on tablespaces, rather than the underlying individual data files.
Bigfile tablespaces are supported only for locally managed tablespaces with automatic segment space management, with three exceptions:
locally managed undo tablespaces, temporary tablespaces, and the SYSTEM tablespace.
System Global Area
The System Global Area (SGA) is a shared memory region that contains data and control information for an Oracle instance. Oracle allocates
the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA. The SGA should be as large
as possible while fitting in real memory to minimize disk I/O.
The information stored in the SGA is divided into several types of memory structures, including the database buffers, redo log buffer, and
the shared pool.
Redo log
Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure. The redo log
consists of two or more files. The database requires a minimum of two files to guarantee that one is always available for writing while the
other is being archived (if the database is in ARCHIVELOG mode).
The redo log is also referred to as a redo thread. In typical configurations, only one database instance accesses an Oracle Database and
only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single
database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo
log files, eliminating a potential performance bottleneck.
Redo records are buffered in a circular fashion in the redo log buffer of the SGA and are written to one of the redo log files by the Log
Writer (LGWR) database background process. When a transaction is committed, LGWR writes the redo records from the redo log buffer of the
SGA to a redo log file and assigns a system change number (SCN) to identify them. Only when all redo records associated with a transaction
are safely on disk in the online logs is the user process notified that the transaction has been committed.
Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills or
another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo
records may not be committed. If necessary, the database can roll back these changes.
To protect against redo log failure, Oracle Database allows a multiplexed redo log where two or more identical copies of the redo log can
be automatically maintained in separate locations and LGWR concurrently writes the same information to multiple identical redo log files.
A group consists of a redo log file and its multiplexed copies.
Size and block size of redo log files
The default size of redo log files is OS-dependent and the minimum permitted size is 4 MB.
Unlike the database block size, which can be between 2K and 32K, redo log files always default to a block size that is equal to the physical
sector size of the disk, typically 512 bytes. Newer high-capacity disk drives offer 4KB sector sizes and the database then automatically
creates redo log files with a 4K block size on those disks.
However with a block size of 4K, there is significant increased redo wastage determined by viewing the statistics stored in the V$SESSTAT
and V$SYSSTAT views.
SELECT name, value FROM v$sysstat WHERE name = 'redo wastage';
The default block size can be overridden by using the BLOCKSIZE keyword.
- add a redo log file group with a block size of 512B
ALTER DATABASE ora1 ADD LOGFILE GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log')
SIZE 100M BLOCKSIZE 512 REUSE;
Undo
Undo consists of records of transactions before they are committed.
Undo records are used to
roll back transactions
recover the database (undo any uncommitted changes applied from the redo log to the data files)
provide read consistency by maintaining the before image of the data for users
analyze data as of an earlier point in time by using Oracle Flashback Query
recover from logical corruptions using Oracle Flashback features
Automatic undo management is the default mode for a newly installed database and an auto-extending undo tablespace named UNDOTBS1 is
created during installation by DBCA.If the database contains multiple undo tablespaces, a specific undo tablespace can be specified for use
by setting the UNDO_TABLESPACE initialization parameter,
UNDO_TABLESPACE = undotbs_01
The database can also run in manual undo management mode where undo space is managed through rollback segments and no undo tablespace is
used.
Back
DATABASE OBJECTS
Creating a database
A database is typically created during Oracle software installation. However, a database can also be created after installation when
Oracle Universal Installer (OUI) was used to install software only and a database was not created
another database (and database instance) is wanted on the same host computer as an existing Oracle database
a copy of a database (clone) is needed
A database can be created using the Database Configuration Assistant (DBCA), a graphical tool or the CREATE DATABASE sql statement.
CREATE DATABASE newdb
USER SYS IDENTIFIED BY sys_password
USER SYSTEM IDENTIFIED BY system_password
LOGFILE GROUP 1 ('/u01/app/oracle/oradata/newdb/redo01.log') SIZE 100M,
GROUP 2 ('/u01/app/oracle/oradata/newdb/redo02.log') SIZE 100M,
GROUP 3 ('/u01/app/oracle/oradata/newdb/redo03.log') SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
EXTENT MANAGEMENT LOCAL
DATAFILE '/u01/app/oracle/oradata/newdb/system01.dbf' SIZE 325M REUSE
SYSAUX DATAFILE '/u01/app/oracle/oradata/newdb/sysaux01.dbf' SIZE 325M REUSE
DEFAULT TABLESPACE users
DATAFILE '/u01/app/oracle/oradata/newdb/users01.dbf'
SIZE 500M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE tempts1
TEMPFILE '/u01/app/oracle/oradata/newdb/temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undots
DATAFILE '/u01/app/oracle/oradata/newdb/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
Schemas
A schema is a collection of database objects and is owned by a database user and has the same name as that user. Schema objects are the
logical structures that directly refer to the database's data including tables, views, and indexes. Objects in the same schema can be in
different tablespaces, and a tablespace can hold objects from different schemas.
select * from dba_objects; - all schema objects in the database
select * from all_objects; - objects accessible to current user
select * from user_objects; - objects owned by current user
The ALTER SESSION statement can be used to switch to a different schema. In subsequent SQL statements, this schema name is used as the
schema qualifier when the qualifier is omitted. In addition, the database uses the temporary tablespace of the specified schema for sorts,
joins, and storage of temporary database objects.
ALTER SESSION SET CURRENT_SCHEMA = schema1;
Tables
Oracle Database tables fall into two categories
Relational tables
Relational tables have simple columns and are the most common table type. They can be of the following organizations
A heap-organized table does not store rows in any particular order. The CREATE TABLE statement creates a heap-organized table by default
An index-organized table orders rows according to the primary key values
An external table is a read-only table whose metadata is stored in the database but whose data is stored outside the database
Object tables
The columns correspond to the top-level attributes of an object type.
select * from dba_tables; - all relational tables in the database
select * from all_tables; - tables accessible to the current user
select * from user_tables; - tables owned by the current user
Creating a table in user's own schema requires the CREATE TABLE system privilege and to create a table in another user's schema, the CREATE
ANY TABLE system privilege is needed. Also, the schema owner must have either space quota on the tablespace to contain the table or the
UNLIMITED TABLESPACE system privilege.
CREATE TABLE emp
(emp_id number(10) NOT NULL,
emp_name varchar2(50) NOT NULL,
dept_id number(10),
CONSTRAINT pk_emp_empid PRIMARY KEY (emp_id),
CONSTRAINT fk_emp_deptid FOREIGN KEY (dept_id) REFERENCES dept(id)
) tablespace tbsp_1 storage (initial 50k);
CREATE TABLE t1 ... ROW STORE COMPRESS BASIC; - create table with basic table compression
CREATE TABLE t1 ... ROW STORE COMPRESS ADVANCED; - with advanced row compression
DESCRIBE t1; - show table structure
SELECT dbms_metadata.get_ddl('TABLE','TABLENAME',['SCHEMA']) from dual; - show create script
To drop a table, the table must be contained in the user's schema or the DROP ANY TABLE system privilege is needed. When a table is dropped,
normally the database does not immediately release the space associated with the table but renames the table and places it in a recycle bin,
where it can later be recovered with the FLASHBACK TABLE statement. To immediately release the space associated with the table, the PURGE
clause can be used.
DROP TABLE t1;
DROP TABLE t1 PURGE; - release the space immediately
DROP TABLE t1 CASCADE CONSTRAINTS; - drop any foreign keys referencing this table
Altering tables
RENAME t1 TO t2; - rename table
ALTER TABLE t1 ADD CONSTRAINT pk_t1_col1 PRIMARY KEY (col1); - add a primary key
ALTER TABLE t1 ADD CONSTRAINT uq_t1_col1 UNIQUE (col1); - add a unique constraint
ALTER TABLE t1 ADD CONSTRAINT fk_t1_col1 FOREIGN KEY (col1) REFERENCES t2(col2); - add a foreign key
ALTER TABLE t1 DROP PRIMARY KEY KEEP INDEX; - drop the primary key, keeping the index
ALTER TABLE t1 DROP CONSTRAINT fk_t1_col1; - drop a constraint
ALTER TABLE t1 DROP UNIQUE(col1); - drop a unique constraint
ALTER TABLE t1 DISABLE CONSTRAINT uq_t1_col1; - disable a constraint
ALTER TABLE t1 ENABLE CONSTRAINT uq_t1_col1; - enable a disabled constraint
When a constraint is in the enable novalidate state, all subsequent statements are checked for conformity to the constraint but any
existing data in the table is not checked.
ALTER TABLE t1 ENABLE NOVALIDATE CONSTRAINT fk_t1_col1;
READ ONLY puts the table in read-only mode and any DML statements that affect the table or any SELECT ... FOR UPDATE statements cannot be
issued. DDL statements can be issued as long as they do not modify any table data and operations on indexes associated with the table are
allowed. READ WRITE returns a read-only table to read/write mode.
ALTER TABLE t1 READ ONLY;
ALTER TABLE t1 READ WRITE;
Multiple tables and views can be created and privileges granted in one operation using the CREATE SCHEMA statement. If an individual table,
view or grant fails, the entire statement is rolled back. The below example creates two tables and a view joining data from the two tables.
CREATE SCHEMA AUTHORIZATION scott
CREATE TABLE dept (
deptno NUMBER(3,0) PRIMARY KEY,
dname VARCHAR2(15))
CREATE TABLE emp (
empno NUMBER(5,0) PRIMARY KEY,
ename VARCHAR2(15) NOT NULL,
hiredate DATE DEFAULT (sysdate),
sal NUMBER(7,2),
deptno NUMBER(3,0) NOT NULL
CONSTRAINT fk_emp_dept REFERENCES dept)
CREATE VIEW sales_staff AS
SELECT empno, ename, sal, comm FROM emp WHERE deptno = 30
WITH CHECK OPTION CONSTRAINT sales_staff_cnst
GRANT SELECT ON sales_staff TO human_resources;
Temporary tables
The definition of a temporary table is visible to all sessions, but the data in a temporary table is visible only to the session that
inserts the data into the table.
The ON COMMIT clause indicates if the data in the table is transaction-specific (the default) or session-specific.
DELETE ROWS - the database truncates the table after each commit
PRESERVE ROWS - the table is truncated when the session is terminated
CREATE GLOBAL TEMPORARY TABLE temptbl1
(col1 DATE,
col2 CHAR(20))
ON COMMIT DELETE ROWS;
Partitioned tables
Any table can be partitioned up to a million separate partitions except those tables containing columns with LONG or LONG RAW data types.
For partitioning an index-organized table
partition columns must be a subset of the primary key columns
secondary indexes can be partitioned (both locally and globally)
OVERFLOW data segments are always equipartitioned with the table partitions
Creating a range-partitioned table
CREATE TABLE sales
( prod_id NUMBER(6),
cust_id NUMBER,
bill_date DATE,
quantity_sold NUMBER(3),
amount_sold NUMBER(10,2)
)
PARTITION BY RANGE (bill_date)
( PARTITION sales_q1_2006 VALUES LESS THAN (TO_DATE('01-APR-2006','dd-MON-yyyy')) TABLESPACE tsa,
PARTITION sales_q2_2006 VALUES LESS THAN (TO_DATE('01-JUL-2006','dd-MON-yyyy')) TABLESPACE tsb,
PARTITION sales_q3_2006 VALUES LESS THAN (TO_DATE('01-OCT-2006','dd-MON-yyyy')) TABLESPACE tsc,
PARTITION sales_q4_2006 VALUES LESS THAN (TO_DATE('01-JAN-2007','dd-MON-yyyy')) TABLESPACE tsd);
Indexes
Indexes are optional structures associated with tables and clusters. Primary and unique keys automatically have indexes.
Oracle Database provides several indexing schemes
B-tree indexes - default and the most common
B-tree cluster indexes - defined specifically for cluster
Hash cluster indexes - defined specifically for a hash cluster
Global and local indexes - relate to partitioned tables and indexes
Reverse key indexes - most useful for Oracle Real Application Clusters applications
Bitmap indexes - compact and work best for columns with a small set of values
Function-based indexes - contain the precomputed value of a function/expression
Domain indexes - specific to an application or cartridge
To create an index, the table to be indexed must be in the user's own schema or the user must have the INDEX privilege on the table or the
CREATE ANY INDEX privilege. To drop an index, the index must be in the user's own schema or the user must have the DROP ANY INDEX privilege.
CREATE INDEX ix_t1_col1 ON t1(col1) TABLESPACE users STORAGE (INITIAL 20K NEXT 20k);
DROP INDEX ix_t1_col1;
Oracle Database enforces a UNIQUE key or PRIMARY KEY integrity constraint on a table by creating a unique index on the unique key or primary
key. The index associated with a constraint always takes the name of the constraint, unless specified otherwise.
CREATE UNIQUE INDEX uq_t1_col1 ON t1(col1); - create a unique index explicitly
Listing indexes
select * from dba_indexes where table_name = 't1' and table_owner = 'user1'; - list all indexes for a table
SELECT * FROM dba_ind_columns where table_name = 't1' and table_owner = 'user1'
ORDER BY table_owner, table_name, index_name, column_position; - show indexed columns
Altering indexes
ALTER INDEX ix_name RENAME TO new_name; - rename index
ALTER INDEX ix_t1_col1 STORAGE (NEXT 40); - alter storage parameters
ALTER TABLE t1 ENABLE PRIMARY KEY USING INDEX; - change the storage options of the index to enforce the primary key constraint:
Rebuilding an index using an existing index as the data source enables changing storage characteristics or moving to a new tablespace.
Rebuilding an index based on an existing data source removes intra-block fragmentation.
ALTER INDEX ix_t1_col1 REBUILD;
Indexes can be rebuilt online, so that the base tables can be updated while rebuilding.
ALTER INDEX emp_name REBUILD ONLINE;
When index is made unusable, it is ignored by the optimizer and is not maintained by DML. When one partition of a partitioned index is made
unusable, the other partitions of the index remain valid. An unusable index or index partition must be rebuilt or dropped and recreated
before using it.
ALTER INDEX ix_t1_col1 UNUSABLE;
ALTER INDEX ix_emp_ename MODIFY PARTITION p2_ix_emp_ename UNUSABLE;
Oracle indexes can be monitored to determine whether they are being used.
ALTER INDEX index MONITORING USAGE; - start monitoring
ALTER INDEX index NOMONITORING USAGE;
The view V$OBJECT_USAGE can be queried for the index being monitored to see if the index has been used. The view contains a USED column
whose value is YES or NO, depending upon if the index has been used within the time period being monitored. The view also contains the
start and stop times of the monitoring period and a MONITORING column (YES/NO) to indicate if usage monitoring is currently active.
Each time MONITORING USAGE is specified, the V$OBJECT_USAGE view is reset for the specified index. The previous usage information is
cleared or reset and a new start time is recorded.
Partitioned indexes
Indexes on partitioned tables can either be nonpartitioned or partitioned. As with partitioned tables, partitioned indexes improve
manageability, availability, performance and scalability. They can either be partitioned independently (global indexes) or automatically
linked to a table's partitioning method (local indexes).
Creating a range-partitioned global index
CREATE INDEX ix_sales_amount ON sales(amount)
GLOBAL PARTITION BY RANGE(sale_month)
( PARTITION p_1000 VALUES LESS THAN (1000)
, PARTITION p_10000 VALUES LESS THAN (10000)
, PARTITION p_100000 VALUES LESS THAN (100000)
, PARTITION p_1000000 VALUES LESS THAN (1000000)
, PARTITION p_greater_than_1000000 VALUES LESS THAN (maxvalue));
Stored Procedures
The CREATE PROCEDURE privilege is required to create/replace a procedure in the user's own schema and the CREATE ANY PROCEDURE privilege is
needed for other schemas.
Creating a procedure:
Create .sql file in notepad and open from sqlplus
1 CREATE OR REPLACE PROCEDURE skeleton
2 IS
3 BEGIN
4 DBMS_OUTPUT.PUT_LINE('Hello World!');
5* END;
SQL>
To execute the contents of the SQL*Plus buffer:
SQL> /
Procedure created.
SQL>
The procedure is created, compiled and saved on the database. To run the procedure,
SQL> SET SERVEROUTPUT ON;
SQL> EXECUTE skeleton;
SQL*Plus assures you the procedure executed successfully:
PL/SQL procedure successfully completed.
The procedure can also be run from within an unnamed PL/SQL block from SQL*Plus command prompt:
SQL> BEGIN
2 SKELETON;
3 END;
4 /
PL/SQL procedure successfully completed.
To debug compilation errors, if any:
SQL> SET ARRAYSIZE 1
SQL> SET MAXDATA 60000
SQL> SHOW ERRORS PROCEDURE proc1
Packages
A package is a schema object that groups logically related PL/SQL types, variables, constants, subprograms, cursors and exceptions, which
is compiled and stored in the database and its contents can be shared by many applications.
Reasons to use packages:
better organization during the development process and for granting privileges
declaration of public and private procedures, variables, constants, and cursors
better performance - an entire package is loaded into memory when a procedure within the package is called for the first time in one
operation, as opposed to the separate loads required for standalone procedures. When calls to related packaged procedures occur, no disk I/O
is necessary to execute the compiled code already in memory
a package body can be replaced and recompiled without affecting the specification. Objects that reference a package's constructs (always
via the specification) need not be recompiled unless the package specification is also replaced, minimizing unnecessary recompilations
Package specification
A package specification declares public items. The scope of a public item is the schema of the package and a public item is visible
everywhere in the schema. A public item that is in scope but not visible can be referenced by qualifying it with the package name.
create or replace package App1dbPackage
as
type Appcursor is ref cursor;
procedure App1Selectproc ( Appcursor1 OUT Appcursor);
procedure App1Deleteproc;
end App1dbPackage;
create or replace package body App1dbPackage as
procedure App1Selectproc (Appcursor1 OUT Appcursor)
IS
BEGIN
open Appcursor1 for
select a.upc_cd, a.sku_num, b.desc, b.class_cd, b.itm_price
from UPC_AUDIT a inner JOIN ITEM b on b.itm_cd = substr(a.sku_num,1,8)
where a.xfer_dt_time is null
order by a.sku_num;
END App1Selectproc;
procedure App1Deleteproc
IS
BEGIN
update UPC_AUDIT
set xfer_dt_time = current_date
where xfer_dt_time is null;
commit;
END App1Deleteproc;
END App1dbPackage;
Triggers
Database triggers can be associated with a table, schema, or database. They are implicitly fired when
- DML statements are executed (INSERT, UPDATE, DELETE) against an associated table
- certain DDL statements are executed (e.g ALTER, CREATE, DROP) on objects within a database or schema
- a specified database event occurs (e.g STARTUP, SHUTDOWN, SERVERERROR)
CREATE OR REPLACE TRIGGER DeleteCustomer
BEFORE DELETE ON Customer
FOR EACH ROW
BEGIN
INSERT INTO CustomerHistory
VALUES(:Old.CUSTOMERID, :Old.LastName, :Old.FirstName);
END DeleteCustomer;
A trigger can be removed from the database by issuing the DROP TRIGGER statement.
ALTER TRIGGER trig1 ENABLE/DISABLE;
ALTER TABLE t1 ENABLE/DISABLE ALL TRIGGERS;
Data dictionary
The data dictionary is the set of read-only reference tables and views that provide administrative metadata about the database.
Views with the prefix DBA_ show all relevant information in the entire database.
Views with the prefix ALL_ return information about schema objects to which the user has access through public or explicit grants of
privileges and roles, in addition to schema objects that the user owns.
Views with the prefix USER_ refer to the user's private environment in the database, including metadata about schema objects created by the
user, grants made by the user and so on.
The DUAL Table
DUAL is a small table in the data dictionary that Oracle Database and user-written programs can reference to guarantee a known result. The
dual table is useful when a value must be returned only once, for e.g, the current date and time. All database users have access to DUAL.
The DUAL table has one column called DUMMY and one row containing the value X.
SQL> SELECT ((3*4)+5)/3 FROM DUAL; - returns 5.66666667
Static Data Dictionary Views
These tables and views are called static because they change only when a change is made to the data dictionary (for e.g when a new table is
created or when a user is granted new privileges).
all_objects - describes all objects accesible to the current user
dba_objects - describes all objects in the database
Columns:
owner
object_name
object_id - dictionary object number of the object
object type
temporary - whether the object is temporary
generated - whether system-generated
user_objects - all objects owned by the current user
The recycle bin
The recycle bin is a data dictionary table containing information about dropped objects. Dropped tables and any associated objects such as
indexes, constraints, nested tables are not removed and occupy space. They continue to count against user space quotas, until specifically
purged from the recycle bin or purged by the database because of tablespace space constraints.
SELECT * FROM RECYCLEBIN; -- synonym
SELECT * FROM USER_RECYCLEBIN; -- view
Back
THE ORACLE SQL LANGUAGE
PL/SQL is Oracle's procedural language extension to SQL. The PL/SQL language includes OOP techniques such as encapsulation, function
overloading, information hiding (all but inheritance). PL/SQL is commonly used to write data-centric programs to manipulate data in an
Oracle database. Internally the Oracle database supports two procedural languages - PL/SQL and Java.
Differences to using PL/SQL and Java in Oracle
PL/SQL
Data centric and tightly integrated into the database
Proprietary to Oracle and difficult to port to other database systems
Data manipulation is slightly faster in PL/SQL than in Java
Java
Open standard, not proprietary to Oracle
Incurs some data conversion overhead between the Database and Java type systems
Datatypes
Oracle datatypes are of four categories:
Scalar - Single values with no internal components
Composite - Data items that have internal components that can be accessed individually
Reference - Pointers to other data items
Large Object (LOB) - Pointers to large objects that are stored separately from other data items, such as text, images, video clips and
sound waveforms
Scalar datatypes
Numeric
PLS_INTEGER or BINARY_INTEGER Signed integer in range -2,147,483,648 through 2,147,483,647, represented in 32 bits
BINARY_FLOAT Single-precision IEEE 754-format floating-point number
BINARY_DOUBLE Double-precision IEEE 754-format floating-point number
NUMBER Fixed-point or floating-point number with absolute value in range 1E-130 to (but not including) 1.0E126
DEC, DECIMAL, or NUMERIC Fixed-point NUMBER with maximum precision of 38 decimal digits
DOUBLE PRECISION or FLOAT Floating-point NUMBER with maximum precision of 126 binary digits (approximately 38 decimal digits)
INT, INTEGER, or SMALLINT Integer with maximum precision of 38 decimal digits
REAL Floating-point NUMBER with maximum precision of 63 binary digits (approximately 18 decimal digits)
Character
CHAR Fixed-length character string with maximum size of 32,767 bytes
VARCHAR2 Variable-length character string with maximum size of 32,767 bytes
RAW Variable-length binary or byte string with maximum size of 32,767 bytes, not interpreted by PL/SQL
NCHAR Fixed-length national character string with maximum size of 32,767 bytes
NVARCHAR2 Variable-length national character string with maximum size of 32,767 bytes
LONG Variable-length character string with maximum size of 32,760 bytes
LONG RAW Variable-length binary or byte string with maximum size of 32,760 bytes, not interpreted by PL/SQL
ROWID Physical row identifier, the address of a row in an ordinary table
UROWID Universal row identifier (physical, logical, or foreign row identifier)
Boolean
BOOLEAN Stores True, False or Null
Date/Time
DATE contains the datetime fields YEAR, MONTH, DAY, HOUR, MINUTE and SECOND. Size is fixed at 7 bytes
TIMESTAMP Year, month and day values of date, as well as hour, minute and second values of time
YEAR -4712 to 9999 (excluding year 0)
MONTH 01 to 12
DAY 01 to 31
HOUR 00 to 23
MINUTE 00 to 59
SECOND 00 to 59.9(n), where 9(n) is the precision of time fractional seconds
TIMEZONE_HOUR -12 to 14 (range accommodates daylight savings time changes)
TIMEZONE_MINUTE 00 to 59
TIMEZONE_REGION Found in the dynamic performance view V$TIMEZONE_NAMES
TIMEZONE_ABBR Found in the dynamic performance view V$TIMEZONE_NAMES
Large objects
BFILE Used to store large binary objects in operating system files outside the database. Cannot exceed 4 GB
BLOB Used to store large binary objects in the database. 8 to 128 TB
CLOB Used to store large blocks of character data in the database. 8 to 128 TB
NCLOB Used to store large blocks of NCHAR data in the database. 8 to 128 TB
Operators
Arithmetic
+ - * /
Concatenation
||
Set operators
Multiple queries can be combined using the set operators UNION, UNION ALL, INTERSECT and MINUS. The set operators are not valid on columns
of type BLOB, CLOB, BFILE, VARRAY or nested table
UNION
UNION ALL
INTERSECT - all distinct rows selected by both queries
MINUS - all distinct rows selected by the first query but not the second
Conditions
Comparison
= != <> >= <=
ANY
SOME
ALL
Logical
AND
OR
NOT
Null
IS [NOT] NULL
Others
BETWEEN
EXISTS
IN
LIKE
Statements
Administrative statements
ANALYZE - validate/gather statistics about a table
ANALYZE TABLE t1 VALIDATE STRUCTURE; - throws an error if the structure is corrupt
ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE; - validate dependent objects (like indexes) as well
ANALYZE TABLE emp VALIDATE STRUCTURE CASCADE FAST; - checks for corruption faster using an optimized algorithm
DDL statements
COMMENT - add comments to the data dictionary about a table, column or view
CREATE TABLE
CREATE TABLESPACE
ALTER TABLE
DROP TABLE
PURGE - remove a table or index from the recycle bin and release all of the space associated with the object or clear the entire
recycle bin
PURGE TABLE t1;
PURGE RECYCLEBIN;
TRUNCATE TABLE - remove all records from a table and free up all the space allocated for the removed records
TRUNCATE TABLE t1 DROP STORAGE; - the default option, reduces the number of extents allocated to the resulting table to the original
setting for MINEXTENTS and freed extents are returned to the system
TRUNCATE TABLE t1 DROP ALL STORAGE; - drops the segment
TRUNCATE TABLE t1 REUSE STORAGE; - all space currently allocated to the table remains allocated to it
DML statements
CALL - execute a routine (a standalone procedure/function or a procedure/function defined within a type or package) from within SQL
DELETE - deletes all records from a table, the space for the records remains
EXPLAIN PLAN - explain access path to data
INSERT
LOCK TABLE - control concurrency
MERGE - used to select rows from one or more tables/views for update or insertion into a table/view combining multiple operations
MERGE INTO bonuses b USING (SELECT emp_id, salary FROM employees) e ON (b.emp_id = e.emp_id)
WHEN MATCHED THEN UPDATE SET b.bonus = b.bonus + e.salary*.01
DELETE WHERE (e.salary > 8000)
WHEN NOT MATCHED THEN INSERT (b.emp_id, b.bonus) VALUES (e.emp_id, e.salary*.01) WHERE (e.salary <= 8000);
SELECT
UPDATE
DCL statements
COMMIT
GRANT
REVOKE
ROLLBACK
SAVEPOINT - identify a point in a transaction by creating a name for the system change number (SCN) to which a rollback can be done later. Savepoint names must be distinct within a given transaction
....
SAVEPOINT savpt1;
....
ROLLBACK TO SAVEPOINT savpt1;
SET TRANSACTION - Change transaction options like what rollback segment to use
Comments
Oracle SQL supports two comment styles - single-line and multi-line. Single-line comments begin with a double hyphen (--) anywhere on a line
and extend to the end of the line. Multi-line comments begin with a /* and end with a */.
Functions
Aggregate functions
AVG
COUNT
FIRST
LAST
MAX
MIN
STDDEV
SUM
VARIANCE
Analytic
RANK/DENSE_RANK - returns the rank of each row in a query. RANK gives non-consecutive ranks in case of ties, while DENSE_RANK doesn't.
select emp_name, salary, RANK() OVER (PARTITION BY dept ORDER BY salary) from employees;
ROW_NUMBER - assigns a unique number to each row to which it is applied
SELECT dept_id, last_name, emp_id,
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY emp_id) AS emp_no FROM employees;
DEPT_ID LAST_NAME EMPLOYEE_ID EMP_NO
------- ------------------------- ----------- ----------
10 Whalen 200 1
20 Hart 201 1
20 Fay 202 2
30 Raphael 114 1
30 Ken 115 2
30 Banner 116 3
SELECT last_name FROM (SELECT last_name, ROW_NUMBER() OVER (ORDER BY last_name) R
FROM employees) WHERE R BETWEEN 51 and 100; - returns rows 51 thru 100
Conversion
CAST(expr as datatype)
select CAST(col1 AS varchar2(30)) from t1;
select CAST('22-OCT-2001' AS TIMESTAMP WITH LOCAL TIME ZONE) from t1;
TO_DATE(char,[fmt],[nlsparam]) - converts CHAR, VARCHAR2, NCHAR or NVARCHAR2 data type values to a value of DATE data type. fmt is a
datetime model format specifying the format of char. If fmt is omitted then char must be in the default date format. The default date format
is determined implicitly by the NLS_TERRITORY initialization parameter or can be set explicitly by the NLS_DATE_FORMAT parameter.
SELECT TO_DATE( '5 Jan 2011', 'DD MON YYYY' ) FROM t1; - returns '05-JAN-11'
TO_NUMBER(expr) - converts expr to a value of NUMBER data type
Datetime
CURRENT_DATE - returns the current date in the time zone of the current SQL session
LAST_DAY(date) - the last day of the month based on a date
NEXT_DAY(date, weekday) - the first weekday that is greater than a date
SYSDATE - current date and time set for the OS on which the database resides
Numeric
CEIL(number) - the smallest integer value that is greater than or equal to a number
FLOOR(number) - the largest integer value that is equal to or less than a number
TRUNC(number) - truncates the number to the provided decimal places (default=0)
TRUNC (125.821) -- 125
TRUNC (125.821,2) -- 125.81
TRUNC (125.821,-1) -- 120
String
ASCII(char) - returns the ASCII value of a character
CHR(ascii_code) - returns the character for the ascii code
CONCAT(str1,str2) - concatenate two strings (use || for multiple strings)
CONVERT(str, charset1, charset2) - converts a string from one character set to another
LENGTH(str) - returns the length using characters as defined by the input character set. LENGTHB uses bytes instead of characters. LENGTHC uses Unicode complete characters, LENGTH2 uses UCS2 code points and LENGTH4 uses UCS4 code points
LPAD/RPAD
SELECT LPAD('4',3,'0'); - returns '0004'
LTRIM/RTRIM(str1[, str2]) - removes from the left/right end of str1 all of the characters contained in str2. If str2 is not specified, it defaults to a single blank
SELECT name, LTRIM(name, 'Monitor ') "Short Name" FROM products WHERE name LIKE 'Monitor%';
NAME Short Name
----------------- ---------------
Monitor 17/HR 17/HR
Monitor 17/HR/F 17/HR/F
REPLACE(str1,str2,str3) - replace all occurrences of str2 in str1 with str3
SOUNDEX(str) - returns a string containing the phonetic representation of the argument. The argument can be of any of the datatypes CHAR, VARCHAR2, NCHAR or NVARCHAR2 and the return value is of the same datatype
SELECT last_name, first_name FROM hr.employees WHERE SOUNDEX(last_name) = SOUNDEX('SMYTHE');
LAST_NAME FIRST_NAME
---------- ----------
Smith Lindsey
Smith William
Others
COALESCE(exp1,exp2...) - returns the first non-null expression in the list
NVL(expr, replace_with) - test an expression for a NULL and return a substitute value
SELECT NVL(NULL, 'n/a'); - returns 'n/a'
Pseudocolumns
A pseudocolumn behaves like a table column but is not actually stored in the table. Pseudocolumns can be selected from but cannot be
inserted, updated or deleted. A pseudocolumn is similar to a function without arguments.
Rowid
The ROWID pseudocolumn returns the address of each row in the database. Oracle Database rowid values contain information necessary to locate
a row
the data object number of the object
the data block in the data file in which the row resides
the position of the row in the data block (first row is 0)
the data file in which the row resides (first file is 1). The file number is relative to the tablespace
Values of the ROWID pseudocolumn have the data type ROWID or UROWID. Usually a rowid value uniquely identifies a row in the database.
However rows in different tables that are stored together in the same cluster can have the same rowid.
Rowid values have several important uses
they are the fastest way to access a single row
they can show you how the rows in a table are stored
they are unique identifiers for rows in a table
Eliminating duplicate rows from a table using Rowid
DELETE FROM t1 A WHERE ROWID > (SELECT min(rowid) FROM t1 B WHERE A.key_values = B.key_values);
Rownum
For each row returned by a query, the ROWNUM pseudocolumn returns a number indicating the order in which Oracle selects the row from a
table or set of joined rows. The first row selected has a ROWNUM of 1, the second has 2 and so on.
Rownum can be used to limit the number of rows returned by a query.
SELECT * FROM employees WHERE ROWNUM < 10;
If an ORDER BY clause follows ROWNUM in the same query, then the rows will be reordered by the ORDER BY clause. The results can vary
depending on the way the rows are accessed. For e.g if the ORDER BY clause causes Oracle to use an index to access the data, then the rows
may be in a different order than without the index.
If the ORDER BY clause is embedded in a subquery and ROWNUM is placed in the top-level query, then ROWNUM is applied after the ordering of
the rows.
SELECT * FROM
(SELECT * FROM employees ORDER BY employee_id) WHERE ROWNUM < 11; - returns the employees with the 10 smallest ids
Conditions testing for ROWNUM values greater than a positive integer are always false.
SELECT * FROM employees WHERE ROWNUM > 1; - returns no rows
The first row fetched is assigned a ROWNUM of 1 and makes the condition false. The second row to be fetched is now the first row and is
also assigned a ROWNUM of 1 and makes the condition false. All rows subsequently fail to satisfy the condition.
ROWNUM can also be used to assign unique values to each row of a table.
UPDATE t1 SET col1 = ROWNUM;
Cursors
DECLARE
var1 upc.itm_cd%TYPE; /* Output variables to hold the result of the query: */
var2 upc.sku_num%TYPE;
CURSOR Cursor1 IS
SELECT upc_cd, sku FROM UPC WHERE rownum < 1000
FOR UPDATE
BEGIN
OPEN Cursor1;
LOOP
FETCH Cursor1 INTO var1, var2;
EXIT WHEN Cursor1%NOTFOUND;
DELETE FROM upc WHERE CURRENT OF Cursor1;
INSERT INTO upc VALUES(var2, var1);
END LOOP;
CLOSE Cursor1;
END;
Nested Cursors
The following code fragment implements a nested loop:
DECLARE
CURSOR dept_cur IS
SELECT deptno FROM dept ORDER BY deptno;
-- Employee cursor all employees for a dept number
CURSOR emp_cur (v_dept_no DEPT.DEPTNO%TYPE) IS
SELECT ename FROM emp WHERE deptno = v_dept_no;
BEGIN
FOR dept_rec IN dept_cur LOOP
dbms_output.put_line('Employees in Department '||TO_CHAR(dept_rec.deptno));
FOR emp_rec in emp_cur(dept_rec.deptno) LOOP
dbms_output.put_line('...Employee is '||emp_rec.ename);
END LOOP;
END LOOP;
END;
%TYPE and %ROWTYPE
The %TYPE and %ROWTYPE constructs provide data independence, reduces maintenance costs, and allows programs to adapt as the database changes to meet
new business needs.
%ROWTYPE is used to declare a record with the same types as found in the specified database table, view or cursor. Example:
DECLARE
v_EmpRecord emp%ROWTYPE;
%TYPE is used to declare a field with the same type as that of a specified table's column. Example:
DECLARE
v_EmpNo emp.empno%TYPE;
Back
ORACLE ADMINISTRATION
Installing Oracle
Oracle editions
Oracle Database is available in five editions, suitable for different development and deployment scenarios. Oracle also offers database
options, packs and other products that enhance the capabilities of Oracle Database for specific purposes.
Standard Edition One - suitable for workgroup, department-level and Web applications, from single-server environments for small business to
highly distributed branch environments.
Standard Edition - Offers the power and performance of Standard Edition One, with support for larger machines and clustering of services
with Oracle Real Application Clusters (Oracle RAC).
Enterprise Edition - ideal for high-volume online transaction processing (OLTP) applications, query-intensive data warehouses and
demanding Internet applications.
Express Edition (XE) - is an entry-level edition of Oracle Database that is simple to install and manage and is free to develop, deploy and
distribute. Oracle Database XE can be installed on any size machine with any number of CPUs, stores up to 11 GB of user data, using up to
1 GB of memory and using only one CPU on the host machine.
Personal Edition - supports single-user development and deployment environments. Personal Edition includes all of the components and options
that are available with Enterprise Edition, with the exception of the Oracle RAC option, which cannot be used with Personal Edition. The
Management Packs are not included in Personal Edition.
Oracle Database 12c
- introduces a new multitenant architecture that makes it easy to consolidate many databases quickly and manage them as a cloud service
- includes in-memory data processing capabilities delivering breakthrough analytical performance
- Additional database innovations deliver new levels of efficiency, performance, security, and availability
- comes in two editions Enterprise Edition and Standard Edition 2
Connecting to Oracle
SQL*Plus
SQLPlus is the command line interface to an Oracle server/database. Connection can be made to a remote Oracle database via
from within SQL*Plus, using the CONNECT command
CONNECT SCOTT@net_service_name
CONNECT SCOTT/TIGER@net_service_name
as SQL*Plus is started, using the SQLPLUS command
SQLPLUS SCOTT@net_service_name
SQLPLUS SCOTT/TIGER@net_service_name
sqlplus USER/PASSWORD@//PODS.GATE.COM:1521/SID12
sqlplus scott/tiger@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=tkyte-pc.us.oracle.com)
(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ora10g)))
The net_service_name usually includes the Oracle SID (server instance identifier), database port number for client connections and Oracle
userid/password.
SQL*Plus commands
CONNECT/CONN username[/password] - connects a username to Oracle
EDIT [filename] - edit contents of the SQL buffer or file
EXIT/QUIT - commits or rolls back all pending changes, logs out of Oracle, terminates SQL*Plus and returns control to the OS
HELP [INDEX | topic] - list help topics
LIST - list contents of the SQL buffer
PASSWORD/PASSW - change password
RUN - list and execute commands stored in the SQL buffer
SHUTDOWN [ABORT | IMMEDIATE | NORMAL] - shuts down a currently running Oracle instance
ABORT - proceeds with the fastest possible shutdown of the database without waiting for calls to complete or users to disconnect.
Uncommitted transactions are not rolled back. Client SQL statements currently being processed are terminated and all currently connected
users are implicitly disconnected and the next database startup will require instance recovery. This option must be used if a background
process terminates abnormally.
NORMAL - the default option which waits for users to disconnect from the database and further connects are prohibited. The database is
closed and dismounted, the instance is shutdown and no instance recovery is required on the next database startup.
Oracle Net Services
Oracle Net Services provides enterprise wide connectivity solutions in distributed, heterogeneous computing environments and ease the
complexities of network configuration and management, maximize performance and improve network diagnostic capabilities.
Oracle Net services has the following objectives
Location transparency for applications (applications do not need to know the location of servers)
Platform independence for applications. Oracle Call interface (OCI) provides this facility
Protocol independence. The service should run equally on TCP/IP, SPX or any other network protocols
Naming methods - translate a connect identifier to a connect descriptor. They include - local naming (tnsnames.ora), Directory naming,
Oracle names, Host naming, External naming.
To access a net service (such as a database) across the network, a net service name is required. net service
names are either found - in the tnsnames.ora file, Directory server, Oracle Names Server or External Naming services.
sqlnet.ora - is the network configuration file, created during installation.
# SQLNET.ORA Network Configuration File: D:\Oracle\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.
NAMES.DEFAULT_DOMAIN = company.com --> Domain name to attach to names
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME) --> Order in which to search for names
tnsnames.ora - Stands for Transparent Network Substrate. Enables referencing an oracle db by a simple alias.
# TNSNAMES.ORA Network Configuration File: D:\Oracle\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
net_service_name=
(DESCRIPTION=
(ADDRESS=(protocol_address_information))
(CONNECT_DATA=
(SERVICE_NAME=service_name)))
Sample file:
DBASPT =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.18.9.21)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dbaspt)
)
)
extproc_connection_data is a special service name that is used for external procedures.
EXTPROC_CONNECTION_DATA.COMPANY.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)
Back
Starting up and shutting down
When a database is started up, an instance of that database is created. Shutting down a currently running database instance can optionally
close and dismount a database.
Normally an instance is started up by mounting and opening the database and making it available for user connections. A database instance
can be started up with SQL*Plus, Recovery Manager or Oracle Enterprise Manager Cloud Control. If the database is being managed by Oracle
Restart, the recommended way to start the database is with SRVCTL.
STARTUP; - using SQL*Plus
When the database instance is started, it attempts to read the initialization parameters from an SPFILE in a platform-specific default
location. If it finds no SPFILE, then it searches for a text initialization parameter file. A non-default SPFILE can be used if the need
arises.
A one-line text initialization parameter file (e.g /u01/oracle/dbs/spf_init.ora) can be created that contains only the SPFILE parameter.
The value of the parameter is the nondefault server parameter file location. For e.g
SPFILE = /u01/oracle/dbs/test_spfile.ora
The instance can be started up pointing to this initialization parameter file
STARTUP PFILE = /u01/oracle/dbs/spf_init.ora
A database instance can be shut down with SQL*Plus by connecting as SYSOPER, SYSDBA, SYSBACKUP or SYSDG and issuing the SHUTDOWN command.
If managed by Oracle Restart, the recommended way to shut down the database is with the srvctl stop database command.
SHUTDOWN; - normal shutdown (default), waits for all connected users to disconnect
SHUTDOWN IMMEDIATE; - terminates active transactions, rolls back uncommitted changes and disconnects users
SHUTDOWN TRANSACTIONAL; - waits for all current transactions to complete
SHUTDOWN ABORT; - terminates all transactions without rolling back and disconnects users, recovery will be required
Checking version/release
The release of Oracle Database that is currently installed and the release levels of other database components can be identified by querying
the data dictionary view PRODUCT_COMPONENT_VERSION.
select * from product_component_version;
Viewing Listener Status
Listener status is viewed with the Listener Control (lsnrctl) utility to determine if the listener is started and to check listener
properties (such as the TCP/IP port numbers that it is listening on).
The listener status can be viewed by logging into the Oracle Database host computer (with the oracle user account in Linux or as the user
who installed Oracle Database in Windows).
LSNRCTL STATUS
LSNRCTL STOP - stop the listener
LSNRCTL START - start
If the listener is not started, the status displays the following error messages
TNS-12541: TNS:no listener
TNS-12560: TNS:protocol adapter error
TNS-00511: No listener
If the listener is started, a report with below details is displayed
(PORT=1521) - the listener is listening for database connections through Oracle Net on port 1521
(PORT=8080))(Presentation=HTTP) - the listener is listening for database connections through HTTP on port 8080
Service "XE" has 1 instance(s) and Instance "XE", status READY - Oracle Database is properly registered with the listener and is ready
to accept connections
Server configuration
Initialization parameters
Initialization parameters can be specified in a parameter file to start or configure an instance. All initialization parameters are
optional and Oracle has a default value for each parameter which for some parameters may be OS-dependent.
Initialization parameters can be used to
optimize performance by adjusting memory structures, such as the number of database buffers in memory
set database-wide defaults, such as the amount of space initially allocated for a context area when it is created
set database limits, such as the maximum number of database users
specify names of files or directories required by the database
A parameter file is a file that contains a list of initialization parameters and a value for each parameter. Oracle supports the following
two types of parameter files:
Server Parameter Files - A server parameter file is a binary file that acts as a repository for initialization parameters which can
reside on the computer where the Oracle server executes. Initialization parameters stored in a server parameter file are persistent across
instance shutdown and startup.
Initialization Parameter Files - An initialization parameter file is a text file that contains a list of initialization parameters.
The file should be written in the client's default character set.
The name of the initialization parameter file varies depending on the OS. For e.g, it can be in mixed case or lowercase or it can have a
logical name or a variation of the name init.ora. Also supplied is an initdw.ora file, which contains suggested parameter settings for
data warehouses and data marts. A different file name can be chosen for the file.
A sample init.ora file can have the following entries
PROCESSES = 100
OPEN_LINKS = 12
GLOBAL_NAMES = true
The value of a parameter in a parameter file in one of the following ways:
By editing an initialization parameter file - in most cases, the new value takes effect the next time the instance is started
By issuing an ALTER SYSTEM SET ... SCOPE=SPFILE statement to update a server parameter file
By issuing an ALTER SYSTEM RESET ... SCOPE=SPFILE statement to remove a parameter from a server parameter file, causing the default
value to take effect the next time the instance is started
The CREATE SPFILE statement is used to create a server parameter file either from a traditional plain-text initialization parameter file
or from the current system-wide settings.
CREATE SPFILE FROM PFILE = '$ORACLE_HOME/work/t_init1.ora'; - create a default spfile from plain-text parameter file
CREATE SPFILE = 's_params.ora' FROM PFILE = '$ORACLE_HOME/work/t_init1.ora'; - create a non-default spfile
The database can be started up using a default spfile by the SQL*Plus STARTUP command without the PFILE parameter.
STARTUP
To use a non-default spfile, a traditional parameter file needs to be created with the single line
spfile = 's_params.ora'
and this file can be used to start up the database by
STARTUP PFILE=new_param.ora
Monitoring the database
Trace files and the alert log
A trace file is a file that contains diagnostic data used to investigate problems. Each server and background process can write to an
associated trace file. When an internal error is detected by a process, it dumps information about the error to its trace file.
The alert log is a chronological log of messages and errors, and includes the following items
all internal errors (ORA-00600), block corruption errors (ORA-01578) and deadlock errors (ORA-00060) that occur
administrative operations, such as some CREATE, ALTER and DROP statements and STARTUP, SHUTDOWN and ARCHIVELOG statements
messages and errors relating to the functions of shared server and dispatcher processes
errors occurring during the automatic refresh of a materialized view
the values of all initialization parameters that had non-default values at the time the database and instance start
If an operation is successful, a 'completed' message is written in the alert log, along with a timestamp.
The alert log is maintained as both an XML file and a text file, either of which can be viewed with any text editor or the ADRCI utility
can be used to view the XML version of the file with the XML tags stripped.
The alert log and all trace files for background and server processes are written to the Automatic Diagnostic Repository, the location of
which is specified by the DIAGNOSTIC_DEST initialization parameter. The names of trace files are OS-specific but each file usually
includes the name of the process writing the file (such as LGWR and RECO).
To control the size of an alert log, it must be manually deleted when no longer needed. Otherwise the database continues to append to the
file.
The maximum size of all trace files (excluding the alert log) can be controlled using the initialization parameter MAX_DUMP_FILE_SIZE.
Server-generated alerts
A server-generated alert is a notification from the database server of an impending problem. Alerts are automatically generated when a
problem occurs or when data does not match expected values for metrics, such as Physical Reads Per Second, User Commits Per Second,
SQL Service Response Time etc.
An alert message is sent to the predefined persistent queue ALERT_QUE owned by the user SYS. Cloud Control reads this queue and provides
notifications about outstanding server alerts and sometimes suggests actions for correcting the problem. The alerts are displayed on the
Cloud Control Database home page and can be configured to send email or pager notifications to selected administrators. If an alert cannot
be written to the alert queue, a message about the alert is written to the Oracle Database alert log.
Background processes periodically flush the data to the Automatic Workload Repository to capture a history of metric values. The alert
history table and ALERT_QUE are purged automatically by the system at regular intervals.
Performance monitoring data dictionary views
A set of data dictionary views can be queried to monitor an Oracle Database instance.
View Description
---- -----------
V$LOCK lists the locks currently held by Oracle Database and outstanding requests for a lock or latch
DBA_BLOCKERS displays a session if it is holding a lock on an object for which another session is waiting
DBA_WAITERS displays a session if it is waiting for a locked object
DBA_DDL_LOCKS lists all DDL locks held in the database and all outstanding requests for a DDL lock
DBA_DML_LOCKS lists all DML locks held in the database and all outstanding requests for a DML lock
DBA_LOCK lists all locks or latches held in the database and all outstanding requests for a lock or latch
DBA_LOCK_INTERNAL displays a row for each lock or latch that is being held, and one row for each outstanding request for a lock or latch
V$LOCKED_OBJECT lists all locks acquired by every transaction on the system
V$SESSION_WAIT lists the resources or events for which active sessions are waiting
V$SYSSTAT contains session statistics
V$RESOURCE_LIMIT provides information about current and maximum global resource utilization for some system resources
V$SQLAREA contains statistics about shared SQL area and contains one row for each SQL string. Also provides statistics about
SQL statements that are in memory, parsed and ready for execution
V$LATCH contains statistics for nonparent latches and summary statistics for parent latches
Performance Tuning
The Automatic Database Diagnostic Monitor (ADDM)
The ADDM is a self-diagnostic software built into Oracle Database. ADDM examines and analyzes data captured in the Automatic Workload
Repository (AWR) to determine possible performance problems in the database. ADDM then locates the root causes of the performance problems,
provides recommendations for correcting them, and quantifies the expected benefits. The results are displayed as ADDM findings on the
Database Home page in Oracle Enterprise Manager.
Back
TRANSACTION/QUERY MANAGEMENT
Transactions
A transaction is a logical, atomic unit of work that contains one or more SQL statements. Oracle Database assigns every transaction a
unique identifier called a transaction ID. All Oracle transactions obey ACID properties.
A transaction begins when the first executable SQL statement is encountered. An executable SQL statement is a SQL statement that
generates calls to a database instance, including DML and DDL statements and the SET TRANSACTION statement.
A transaction ends when one of the following occurs
a user issues a COMMIT or ROLLBACK statement without a SAVEPOINT clause
a user runs a DDL command such as CREATE, DROP, RENAME or ALTER. The database issues an implicit COMMIT statement before and after
every DDL statement. If the current transaction contains DML statements, then Oracle first commits the transaction and then runs and
commits the DDL statement as a new, single-statement transaction
a user exits normally from most Oracle Database utilities and tools, causing the current transaction to be implicitly committed. The
commit behavior when a user disconnects is application-dependent and configurable
a client process terminates abnormally causing the transaction to be implicitly rolled back using metadata stored in the transaction
table and the undo segment
When a transaction begins, Oracle assigns the transaction to an available undo data segment to record the undo entries for the new
transaction. A transaction ID is not allocated until an undo segment and transaction table slot are allocated, which occurs during the
first DML statement. The transaction ID represents the undo segment number, slot and sequence number.
Committing a transaction
When a transaction commits, the following actions occur:
the database generates an SCN for the COMMIT. The internal transaction table for the associated undo tablespace records that the
transaction has committed. The corresponding unique SCN of the transaction is assigned and recorded in the transaction table
The log writer process (LGWR) process writes remaining redo log entries in the redo log buffers to the online redo log and writes the
transaction SCN to the online redo log. This atomic event constitutes the commit of the transaction
Oracle releases locks held on rows and tables
Oracle deletes savepoints
Oracle Database performs a commit cleanout. If modified blocks containing data from the committed transaction are still in the SGA and
if no other session is modifying them, then the database removes lock-related transaction information (the ITL entry) from the blocks
Oracle marks the transaction complete
System Change Numbers
A system change number (SCN) is a logical, internal time stamp used by Oracle. SCNs order events that occur within the database, which is
necessary to satisfy the ACID properties of a transaction. Oracle uses SCNs to mark the SCN before which all changes are known to be on
disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of
data so that recovery can stop.
SCNs occur in a monotonically increasing sequence. Oracle Database can use an SCN like a clock because an observed SCN indicates a logical
point in time and repeated observations return equal or greater values. If one event has a lower SCN than another event, then it occurred
at an earlier time in the database. Several events may share the same SCN, which means that they occurred at the same time in the database.
Every transaction has an SCN and all modifications in this transaction have the same SCN. When a transaction commits, the database records
an SCN for the commit.
Oracle increments SCNs in the system global area (SGA). When a transaction modifies data, the database writes a new SCN to the undo data
segment assigned to the transaction. The log writer process then writes the commit record of the transaction with the unique SCN
immediately to the online redo log. Oracle also uses SCNs as part of its instance recovery and media recovery mechanisms.
Locking
Automatic locking
A SELECT query without the FOR UPDATE clause acquires no data locks and other transactions can query and update a table being queried,
including the specific rows being queried. Such queries are referred to as nonblocking queries. The query does not have to wait for any
data locks to be released and can always proceed.
Row Locks (TX)
A row lock, also called a TX lock, is a lock on a single row of a table. A transaction acquires a row lock for each row modified by one of
the statements - INSERT, UPDATE, DELETE, MERGE and SELECT ... FOR UPDATE and it exists until the transaction commits or rolls back.
When a transaction obtains a row lock for a row, the transaction also acquires a table lock for the table in which the row resides to
prevent conflicting DDL operations that would override data changes in the transaction.
Table Locks (TM)
A transaction automatically acquires a table lock (TM lock) when a table is modified with the statements - INSERT, UPDATE, DELETE, MERGE
and SELECT ... FOR UPDATE. These DML operations require table locks to reserve DML access to the table on behalf of a transaction and to
prevent DDL operations that would conflict with the transaction.
A table lock can be held in any of the following modes
A row share lock (RS), also called a subshare table lock (SS), indicates that the transaction holding the lock on the table has locked
rows in the table and intends to update them. An SS lock is the least restrictive mode of table lock and offers the highest degree of
concurrency for a table
A row exclusive lock (RX), also called a subexclusive table lock (SX), indicates that the transaction holding the lock has updated
table rows or issued SELECT ... FOR UPDATE. An SX lock allows other transactions to query, insert, update, delete or lock rows
concurrently in the same table. Thus multiple transactions to obtain simultaneous SX and SS locks for the same table.
A share table lock (S) held by one transaction allows other transactions to query the table (without using SELECT ... FOR UPDATE) but
allows updates only if a single transaction holds the share table lock. Multiple transactions may hold a share table lock concurrently, so
holding this lock is not sufficient to ensure that a transaction can modify the table
A share row exclusive table lock (SRX), also called a share-subexclusive table lock (SSX), is more restrictive than a share table lock.
Only one transaction at a time can acquire an SSX lock on a given table. An SSX lock held by a transaction allows other transactions to
query the table (except for SELECT ... FOR UPDATE) but not to update the table
An exclusive table lock (X) is the most restrictive mode of table lock, allowing the transaction that holds the lock exclusive write
access to the table. Only one transaction can obtain an X lock for a table
Manual locking
Automatic locking can be overridden at two levels:
Transaction - transaction-level locking can be overridden with the following SQL statements
SET TRANSACTION ISOLATION LEVEL
LOCK TABLE
SELECT ... FOR UPDATE
Locks acquired by these statements are released after the transaction commits or rolls back.
Session - a session can set the required transaction isolate level with an ALTER SESSION SET ISOLATION LEVEL statement.
Monitoring locks
Oracle provides scripts and views that enable monitoring locks. To monitor locks
run the catblock.sql, which creates lock views
run the utllockt.sql script which uses the views created by catblock.sql to display, in a tree fashion, the sessions in the system
that are waiting for locks and the locks that they are waiting for
The location of the script files is operating system dependent.
The dynamic performance view V$LOCK lists the locks currently held by Oracle and outstanding requests for a lock or latch.
select * from V$LOCK;
Execution plans
An execution plan is the combination of the steps that Oracle Database uses to execute a statement. Each step either retrieves rows of data
physically from the database or prepares them for the user issuing the statement. An execution plan includes an access path for each table
accessed and an ordering of the tables (the join order) with the appropriate join method.
The EXPLAIN PLAN statement displays execution plans that the optimizer chooses for SELECT, UPDATE, INSERT and DELETE statements into the
PLAN_TABLE. The PLAN_TABLE is automatically created as a public synonym to a global temporary table and this temporary table holds the
output of EXPLAIN PLAN statements for all users.
EXPLAIN PLAN FOR SELECT col1 FROM t1;
The most recent plan_table output can be displayed by the DBMS_XPLAN.DISPLAY table function. The function accepts the options:
- a plan table name if a table different than PLAN_TABLE is used
- a statement ID if a statement ID has been set with the EXPLAIN PLAN
- a format option that determines the level of detail: BASIC, SERIAL, TYPICAL and ALL
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY('MY_PLAN_TABLE', 'st1','TYPICAL'));
The plan can also be displayed by querying the V$SQL_PLAN view. V$SQL_PLAN contains the execution plan for every statement stored in the
shared SQL area and its definition is similar to PLAN_TABLE.
Distributed transactions
A distributed database is a set of databases in a distributed system that can appear to applications as a single data source. A distributed
transaction is a transaction that includes one or more statements that update data on two or more distinct nodes of a distributed database,
using a schema object called a database link. A database link describes how one database instance can log in to another database instance.
Unlike a transaction on a local database, a distributed transaction alters data on multiple databases and consequently the database must
coordinate the committing or rolling back of the changes in an entire transaction as an atomic unit. Oracle must coordinate transaction
control over a network and maintain data consistency, even if a network or system failure occurs.
The Two-Phase Commit Mechanism
A two-phase commit mechanism guarantees that all database servers participating in a distributed transaction either all commit or all undo
the statements in the transaction, maintaining data consistency in a distributed database. It also protects implicit DML operations
performed by integrity constraints, RPC calls and triggers.
In a two-phase commit among multiple databases, one database called the global coordinator coordinates the distributed transaction. The
coordinator asks the other databases if they are prepared to commit and if any database responds with a no, then the entire transaction is
rolled back. If all databases vote yes, then the coordinator broadcasts a message to make the commit permanent on each database.
The Oracle two-phase commit mechanism is completely transparent to users who issue distributed transactions and users need not even know
the transaction is distributed. A COMMIT statement automatically triggers the two-phase commit mechanism. No coding or syntax is required
to include distributed transactions within the body of a database application.
The recoverer (RECO) background process automatically resolves the outcome of in-doubt distributed transactions - those in which the commit
was interrupted by a system or network failure. After the failure is repaired and communication is reestablished, the RECO process of each
local Oracle database automatically commits or rolls back any in-doubt transactions consistently on all involved nodes.
In the event of a long-term failure, Oracle allows each local administrator to manually commit or undo any distributed transactions that
are in doubt, enabling the freeing of any locked resources that are held indefinitely as a result of the long-term failure.
If a database must be recovered to a point in the past, Oracle's recovery facilities enable DBAs at other sites to return their databases
to the earlier point in time also. This operation ensures that the global database remains consistent.
Back
USER MANAGEMENT/SECURITY
Creating users
The CREATE USER statement is used to create and configure a database user, an account which can log in to the database.
CREATE USER user1 IDENTIFIED BY pwd1;
Clauses:
EXTERNALLY - creates an external user who must be authenticated by an external service, such as an OS or a third-party service
GLOBALLY - creates a global user who must be authorized by the enterprise directory service (Oracle Internet Directory)
DEFAULT TABLESPACE - the default tablespace for objects created in the user's schema
TEMPORARY TABLESPACE - the tablespace or tablespace group for the user's temporary segments
PASSWORD EXPIRE - forces the user to change the password before logging in
select * from dba_users; - describes all users of the database
select * from all_users; - lists all users visible to the current user
select * from user_users; - describes the current user
Roles and privileges
Roles
Roles are created by users (administrators) to group together privileges or other roles to facilitate the granting of multiple privileges
or roles to users.
select * from dba_roles; - list all roles
select * from dba_role_privs; - roles granted to users and roles
select * from user_role_privs; - roles granted to current user
select * from session_roles; - roles enabled for issuer
Privileges
Privileges are granted or revoked either by a user with the ADMIN privilege or for privileges to a certain object, by the owner of the
object.
select * from session_privs; - privileges enabled for issuer
A user or role that is granted a privilege or role specifiying the WITH ADMIN OPTION clause has several expanded capabilities
The grantee can grant or revoke the privilege or role to or from any user or other role in the database. Users cannot revoke a role
from themselves
The grantee can further grant the system privilege or role with the ADMIN OPTION
The grantee of a role can alter or drop the role
GRANT dba TO user1 WITH ADMIN OPTION;
System privileges
ALTER ANY TABLE - enables to user to alter any table
CREATE ANY TABLE - enables a user to create a table owned by any user in the database
CREATE PROCEDURE - create PL/SQL procedure. function or package owned by the user
CREATE SESSION - enables a user to create a connection to the database
CREATE TABLE
DELETE ANY TABLE
DROP ANY TABLE
EXECUTE ANY PROCEDURE
FLUSH ANY CACHE GROUP - enables a user to flush any cache group
select * from dba_sys_privs; - system privileges granted to users and roles
select * from user_sys_privs; - system privileges granted to the current user
Object privileges
An object privilege is the right to perform an action on an object. Objects include tables, views, materialized views, indexes, synonyms,
sequences, cache groups, replication schemes and PL/SQL functions, procedures and packages.
An object's owner has all object privileges for that object and they cannot be revoked and the object's owner can grant object privileges
for that object to other users. A user with ADMIN privilege can grant and revoke object privileges from users who do not own the objects.
DELETE
EXECUTE
FLUSH - flush a cache group
INDEX
INSERT
LOAD - load a cache group
REFERENCES
SELECT
UNLOAD
UPDATE
select * from dba_tab_privs; - all grants on all objects in the database
select * from all_tab_privs; - grants on objects where the user or PUBLIC is the grantee
select * from user_tab_privs; - grants on all objects where the current user is the grantee
Privilege hierarchy
Some privileges confer other privileges. For e.g ADMIN privilege confers all other privileges and CREATE ANY TABLE system privilege confers
the CREATE TABLE object privilege.
The CACHE_MANAGER privilege confers these privileges
CREATE ANY CACHE GROUP
ALTER ANY CACHE GROUP
DROP ANY CACHE GROUP
FLUSH ANY CACHE GROUP
LOAD ANY CACHE GROUP
UNLOAD ANY CACHE GROUP
REFRESH ANY CACHE GROUP
FLUSH
LOAD
UNLOAD
REFRESH
The CACHE_MANAGER privilege also includes the ability to start and stop the cache agent and the replication agent and to perform cache grid
operations. CREATE ANY CACHE GROUP confers the CREATE CACHE GROUP privilege for any cache group.
The PUBLIC role
All users of the database have the PUBLIC role which by default has SELECT and EXECUTE privileges on various system tables and views and
PL/SQL functions, procedures and packages.
SELECT table_name, privilege FROM sys.dba_tab_privs WHERE grantee='PUBLIC';
Privileges that are granted to PUBLIC as part of database creation cannot be revoked and are listed by
SELECT table_name, privilege FROM sys.dba_tab_privs WHERE grantor='SYS';
All grants/revokes of system and object privileges to users, roles and PUBLIC are immediately observed. All grants/revokes of roles to
users, other roles and PUBLIC are only observed when a current user session issues a SET ROLE statement to re-enable the role after the
grant/revoke or when a new user session is created after the grant/revoke.
Administrative privileges
Oracle Database provides administrative privileges that are tailored for commonly performed specific administrative tasks.
SYSDBA and SYSOPER - enable performing a variety of standard database operations
SYSBACKUP - used to perform backup and recovery operations with either RMAN and SQL*Plus
A predefined DBA role is automatically created with every installation which contains most database system privileges and can be granted
to database administrators.
Encrypted Tablespaces
Any user who can create a tablespace can create an encrypted tablespace.
CREATE TABLESPACE secutbsp
DATAFILE '/u01/app/oracle/oradata/orcl/secutbsp01.dbf' SIZE 100M
ENCRYPTION USING 'AES256' DEFAULT STORAGE(ENCRYPT);
The view V$ENCRYPTED_TABLESPACES lists all currently encrypted tablespaces.
select * from dba_tablespaces where encrypted = 'YES';
SELECT t.name, e.encryptionalg algorithm FROM v$tablespace t, v$encrypted_tablespaces e WHERE t.ts# = e.ts#;
Back
IMPORTING/EXPORTING DATA
SQL*LOADER
SQL*Loader is a bulk loader utility used for moving data from external files into the Oracle database. Its syntax is similar to that of the
DB2 Load utility, but comes with more options. SQL*Loader supports various load formats, selective loading, and multi-table loads.
Loading delimited data
Data can be loaded into an Oracle database by using the sqlldr (sqlload on some platforms)
utility. Invoke the utility without arguments to get a list of available parameters.
sqlldr scott/tiger control=loader.ctl
This sample control file (loader.ctl) will load an external data file containing delimited data:
load data infile 'c:\data\mydata.csv'
into table emp
fields terminated by "," optionally enclosed by '"'
( empno, empname, sal, deptno )
Loading instream data
The below example loads in-line data formatted as fixed-length records. "*" is specified as the name of the data file and BEGINDATA is
used to start the data section in the control file.
load data infile * replace
into table departments
( dept position (02:05) char(4),
deptname position (08:27) char(20)
)
begindata
COSC COMPUTER SCIENCE
ENGL ENGLISH LITERATURE
MATH MATHEMATICS
POLY POLITICAL SCIENCE
Skipping header records
The SKIP n keyword can be used to skip rows at the top.
LOAD DATA INFILE *
INTO TABLE load_positional_data
SKIP 5
( data1 POSITION(1:5),
data2 POSITION(6:15))
BEGINDATA
11111AAAAAAAAAA
22222BBBBBBBBBB
Loading data into multiple tables
LOAD DATA INFILE * REPLACE
INTO TABLE emp
WHEN empno != ' '
( empno POSITION(1:4) INTEGER EXTERNAL,
ename POSITION(6:15) CHAR,
deptno POSITION(17:18) CHAR,
mgr POSITION(20:23) INTEGER EXTERNAL
)
INTO TABLE proj
WHEN projno != ' '
( projno POSITION(25:27) INTEGER EXTERNAL,
empno POSITION(1:4) INTEGER EXTERNAL
)
Transporting Data
Transporting data is much faster than performing either an export/import or unload/load because, for user-defined tablespaces, the data
files containing all of the actual data are copied to the target location and Data Pump is used to transfer only the metadata of the
database objects to the new database.
Data can be transported at any of the following levels:
Database - the full transportable export/import feature can be used to move an entire database to a different database instance
Tablespaces - the transportable tablespaces feature can be used to move a set of tablespaces between databases
Tables, partitions, and subpartitions - the transportable tables feature can be used to move a set of tables, partitions and
subpartitions
Transporting a database using an export dump file
The following list of tasks summarizes the process of transporting a database using an export dump file:
1. At the source database, place each of the user-defined tablespaces in read-only mode and export the database. The following parameters
need to be set to the specified values
TRANSPORTABLE=ALWAYS
FULL=Y
If the source database contains any encrypted tablespaces or tablespaces containing tables with encrypted columns, then either
ENCRYPTION_PWD_PROMPT=YES must be specified or the ENCRYPTION_PASSWORD parameter must be specified.
The export dump file includes the metadata for objects contained within the user-defined tablespaces and both the metadata and data for
user-defined objects contained within the administrative tablespaces, such as SYSTEM and SYSAUX.
2. Transport (copy) the export dump file to a place that is accessible to the target database.
3. Transport (copy) the data files for all of the user-defined tablespaces in the database to a place that is accessible to the target
database. If the source platform's endian format is different from the target platform's endian format, then the data files need to be
converted by using the GET_FILE or PUT_FILE procedure in the DBMS_FILE_TRANSFER package to transfer the data files which convert the data
files to the target platform's endian format automatically or by using the RMAN CONVERT command.
4. (Optional) Restore the user-defined tablespaces to read/write mode on the source database.
5. At the target database, import the database. When the import is complete, the user-defined tablespaces are in read/write mode.
Back
BACKUP/RECOVERY
There are two ways to perform Oracle backup and recovery
Recovery Manager (RMAN) is an Oracle utility that can backup, restore and recover database files. It is a feature of the Oracle database
server and does not require separate installation.
Operating system commands can also be used for backups and SQL*Plus for recovery. This method, also called user-managed backup and recovery,
is fully supported by Oracle, although use of RMAN is highly recommended because it is more robust and greatly simplifies administration.
A consistent backup is one in which the files being backed up contain all changes up to the same system change number (SCN). i.e the files
in the backup contain all the data taken from a same point in time. Unlike an inconsistent backup, a consistent whole database backup does
not require recovery after it is restored.
An inconsistent backup is a backup of one or more database files that are made while the database is open or after the database.
RMAN(Recovery Manager)
RMAN is an Oracle Database client that performs backup and recovery tasks on databases. The RMAN executable is automatically installed with
the database and is typically located in the same directory as the other database executables.
A target database is a database to which RMAN is connected with the TARGET keyword and on which RMAN is performing backup and recovery
operations. RMAN always maintains metadata (RMAN repository) about its operations on a database in the control file of the database.
The RMAN client is started by issuing the rman command at the command prompt of the OS and the RMAN> prompt is displayed.
RMAN connections to a database are specified and authenticated in the same way as SQL*Plus connections to a database except that RMAN
connections to a target or auxiliary database require either the SYSDBA or SYSBACKUP privilege. The CONNECT TARGET command is used to
connect to a database.
% rman
RMAN> CONNECT TARGET "user1@prod AS SYSBACKUP"
target database Password: pswd
connected to target database: PROD (DBID=39525561)
RMAN> SHOW ALL; - show current configuration
Backing up a database
The BACKUP command is used to back up files. RMAN backs up data to the configured default device for the type of backup requested, by
default on disk. If a fast recovery area is enabled and if the FORMAT parameter is not specified, RMAN creates backups in the recovery
area and automatically gives them unique names.
By default, RMAN creates backup sets rather than image copies. A backup set consists of one or more backup pieces, which are physical
files written in a format that only RMAN can access. A multiplexed backup set contains the blocks from multiple input files. RMAN can write
backup sets to disk or tape.
If BACKUP AS COPY is specified, RMAN copies each file as an image copy, which is a bit-for-bit copy of a database file created on disk.
Image copies are identical to copies created with OS commands like cp on Linux or COPY on Windows, but are recorded in the RMAN repository
and so are usable by RMAN. RMAN can make image copies while the database is open.
Backing Up a Database in ARCHIVELOG Mode
If a database runs in ARCHIVELOG mode, it can be backed up while it is open. A backup is called an inconsistent backup if it contains
changes after its checkpoint. If the archived redo logs are available, open database backups are as effective for data protection as
consistent backups.
To back up the database and archived redo logs while the database is open
Start RMAN and connect to a target database
Run the BACKUP DATABASE command to back up the database and all archived redo log files to the default backup device
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Backing Up a Database in NOARCHIVELOG Mode
If a database runs in NOARCHIVELOG mode, then the only valid database backup is a consistent backup. For the backup to be consistent, the
database must be mounted after a consistent shutdown. Recovery is not specifically required after restoring the backup, but any transactions
made after the backup would be lost.
To make a consistent database backup
Start RMAN and connect to a target database
Shut down the database consistently and then mount it
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP FORCE DBA;
RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP MOUNT;
Run the BACKUP DATABASE command to back up the database to the default backup device
RMAN> BACKUP DATABASE;
The following variation of the command creates image copy backups of all data files in the database
RMAN> BACKUP AS COPY DATABASE;
Open the database and resume normal operations.
RMAN> ALTER DATABASE OPEN;
Error codes
ORA-12081: update operation not allowed on table - table is in read-only mode
Back
HIGH AVAILABILITY/SCALABILITY
Oracle Real Application Clusters
A cluster comprises multiple interconnected computers or servers that appear as one server to users and applications. Oracle RAC enables
clustering Oracle databases and uses Oracle Clusterware for the infrastructure to bind multiple servers so they operate as a single system.
Oracle Clusterware is a portable cluster management solution that is integrated with Oracle. Oracle Clusterware is also a required
component for using Oracle RAC and it enables both single-instance Oracle databases and Oracle RAC databases to use the Oracle
high-availability infrastructure. Oracle Clusterware enables the creation of a clustered pool of storage to be used by any combination of
single-instance and Oracle RAC databases.
Oracle Clusterware is the only clusterware needed for most platforms on which Oracle RAC operates but clusterware from other vendors can
also be used if certified for Oracle RAC.
Single-instance Oracle databases have a one-to-one relationship between the Oracle database and the instance. Oracle RAC environments,
however, have a one-to-many relationship between the database and instances. An Oracle RAC database can have up to 100 instances, all of
which access one database. All database instances must use the same interconnect, which can also be used by Oracle Clusterware.
Oracle RAC databases differ architecturally from single-instance Oracle databases in that each Oracle RAC database instance also has
at least one additional thread of redo for each instance
an instance-specific undo tablespace
The combined processing power of the multiple servers can provide greater throughput and Oracle RAC scalability than is available from a
single server.
Oracle Clusterware
Oracle Clusterware provides a complete, integrated clusterware management solution on all Oracle Database platforms. It provides all of
the features required to manage a cluster database including node membership, group services, global resource management and high
availability functions. Oracle Clusterware can be installed independently or as a prerequisite to the Oracle RAC installation process.
Oracle Database features such as services use the underlying Oracle Clusterware mechanisms to provide their capabilities.
Oracle Clusterware is designed for and tightly integrated with Oracle RAC. When an Oracle RAC database is created using any of the
management tools, the database is registered with and managed by Oracle Clusterware along with the other database processes such as
Virtual Internet Protocol (VIP) address, Global Services Daemon (GSD), the Oracle Notification Service (ONS) and the Oracle Net listeners.
These resources are automatically started when Oracle Clusterware starts the node and automatically restarted if they fail. The Oracle
Clusterware daemons run on each node.
Oracle Clusterware can be used to manage high-availability operations in a cluster. Anything that Oracle Clusterware manages is known as
a CRS resource, which could be a database, an instance, a service, a listener, a VIP address, an application process and so on. Oracle
Clusterware manages CRS resources based on the resource's configuration information that is stored in the Oracle Cluster Registry (OCR).
Master replication
Oracle has two types of master replication - single master replication and multimaster replication.
Multimaster replication - includes multiple master sites, where each master site operates as an equal peer
Single master replication - a single master site supporting materialized view replication provides the mechanisms to support
potentially hundreds or thousands of materialized view sites
A single master site that supports materialized view sites can also participate in a multiple master site environment, creating a hybrid
replication environment (combination of multimaster and materialized view replication).
Multimaster replication process
There are two types of multimaster replication
Asynchronous replication - often referred to as store-and-forward replication, captures any local changes, stores them in a queue and
at regular intervals, propagates and applies these changes at remote sites. There is a period of time before all sites achieve data
convergence
Synchronous replication - also known as real-time replication, applies any changes or executes any replicated procedures at all sites
as part of a single transaction. If the DML statement or procedure fails at any site, then the entire transaction rolls back. Synchronous
replication ensures data consistency at all sites in real-time
Back
TOOLS/UTILITIES
Oracle Application Express (APEX)
Oracle Application Express is a web-based RAD tool that runs on an Oracle database useful for designing web applications. APEX comes
standard at no additional cost with all Oracle Database editions and is installed by default as part of the core database install.
Oracle APEX uses a simple 3-tier architecture where requests are sent from the browser through a web server to the database. A web request
from the browser is sent to Oracle REST Data Services (ORDS) where it is handed to Oracle Database to be actioned. Within the database, the
request is processed by Oracle APEX. Once the processing is complete, the result is sent back through ORDS to the browser.
When users log in to Oracle APEX, they log in to a shared work area called a workspace. A workspace is a virtual private database allowing
multiple users to work within the same APEX installation while keeping their objects, data and applications private. Each workspace has a
unique numeric ID and name.
SQL Developer
Oracle SQL Developer is a free graphical tool designed to improve productivity and simplify the development of SQL tasks - browsing and
managing database objects, executing SQL, creating reports etc. It is developed in Java, leveraging the Oracle JDeveloper IDE.
SQL Developer can be installed on the server and remotely accessed from the desktop, avoiding client/server network traffic. It has two
main tabs - Connections and Reports.
In Windows, if the tnsnames.ora file exists but SQL Developer is not using its connections, TNS_ADMIN should be defined as a system
environment variable. Connections can be exported to an XML file and be reused.
Connection types
Basic - The hostname and SID (system identifier) of the DB are entered
TNS - any of the DB aliases imported from the tnsname.ora file is used
Advanced - a custom JDBC URL is used
The SQL Worksheet that is part of the SQL Developer can execute SQL, PL/SQL and many SQL*Plus commands. Non-supported SQL*Plus commands are ignored and not sent to
the Oracle DB.
Oracle Forms
Oracle Forms is a Rapid Application Development (RAD) environment. It is comprised of the following components:
Forms Builder is used to create applications to enter, access, change, or delete data from Oracle (and other) databases.
The Forms Runtime environment is required to execute compiled Forms modules.
Oracle Internet Application Server (iAS) Forms Services is used to deploy Forms across the Web.
Oracle GoldenGate
Oracle GoldenGate enables the transfer of data at the transaction level among multiple, heterogeneous platforms. It moves committed
transactions with integrity and minimal overhead. It can be used to extract and replicate selected data records, transactional changes and
DDL changes across a variety of topologies.
Oracle GoldenGate can be configured for:
A static extraction of records from one database and loading to another database
Continuous extraction and replication of transactional DML operations and DDL changes to keep source and target data consistent
Extraction from a database and replication to a file outside the database
GoldenGate has the following components
Extract - runs on the source system and writes to a trail
Data pump - reads the trail and sends the data operations over the network to a remote trail on the target
Replicat - reads the trail on the target and reconstructs the DML or DDL operations and applies them to the target database
Trails or extract files - series of files storing captured changes
Checkpoints - store the current read and write positions of a process to disk for recovery purposes and prevent loss of data
Manager - the control process of Oracle GoldenGate. Manager must be running on each system in the GoldenGate configuration before
Extract or Replicat can be started and must remain running while those processes are running.
Manager performs the following functions
Start Oracle GoldenGate processes
Start dynamic processes
Maintain port numbers for processes
Perform trail management
Create event, error, and threshold reports
Collector - process that runs in the background on the target system when continuous, online change synchronization is active. Collector
does the following
- Upon a connection request from a remote Extract to Manager, scan and bind to an available port and then send the port number to Manager
for assignment to the requesting Extract process
- Receive extracted database changes that are sent by Extract and write them to a trail file. Manager starts Collector automatically when
a network connection is required. Collector can receive information from only one Extract process, so there is one Collector for each
Extract and Collector terminates when the associated Extract process terminates
Oracle Enterprise Manager Cloud Control
Enterprise Manager is a system management software that delivers centralized monitoring, administration and life cycle management
functionality for cloud computing environments - from Oracle Database instances to Oracle Real Application Clusters to Oracle Application
Server Farms and Clusters. It offers support for monitoring even some non-Oracle products.
EM is built with the following software components
Oracle Management Service (OMS) - responsible for communicating with Management Agents and a central repository that stores
information
Oracle Management Agent - responsible for collecting information from the monitored targets and transporting them
to OMS. The Management Agent on each monitored host monitors the status, health, and performance of all managed components (targets) on
that host. If a target goes down, or if a performance metric crosses a warning or critical threshold, an alert is generated and sent to
Enterprise Manager administrators
Oracle Management Repository - repository configured in Oracle Database to store the collected information
Cloud Control console - user interface that displays information about the health of the monitored targets. Performance problems such
as poorly performing SQL and recommendations generated by ADDM are also captured and exposed through the console
Back
Maintained by: VINCENT KANDASAMY, Database Architect/Administrator (kandasf@hotmail.com)
Last updated: Dec 14, 15:50