TechnoBase DBMS | MySQL | SQL Server | PostgreSQL | Unix/Linux
Oracle
Oracle architecture ---- Tablespaces -------- Locally managed tablespaces -------- Bigfile tablespaces ---- Redo log ---- Undo Database objects ---- Tables -------- Partitioned tables ---- Indexes ---- Stored procedures ---- Data dictionary The Oracle SQL language ---- Datatypes ---- Operators ---- Conditions ---- Functions ---- Pseudocolumns Server administration ---- Installing Oracle ---- Connecting to Oracle --------SQL*Plus ---- Startup and shutdown ---- Server configuration -------- Initialization parameters ---- Monitoring the database -------- Trace files and the alert log -------- Performance monitoring data dictionary views ---- Performance tuning Transaction/Query management ---- Transactions ---- Locking -------- Monitoring locks ---- Execution plans ---- Distributed transactions -------- The two-phase commit mechanism User management/Security ---- Creating users ---- Roles and privileges Importing/Exporting data ---- SQL*Loader ---- Transporting data Backup/Recovery ---- RMAN(Recovery Manager) ---- Error codes High availability/Scalability ---- Oracle Real Application Clusters(RAC) -------- Oracle Clusterware ---- Master replication Tools/Utilities ---- Oracle Application Express ---- SQL Developer ---- Oracle GoldenGate ---- Oracle Enterprise Manager Cloud Control


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