Oracle Automatic Storage Management - Concepts


  • Oracle ASM is a volume manager and a file system for Oracle database files.
  • It supports single-instance and Oracle RAC configurations.
  • Oracle ASM also supports a general purpose file system that can store application files and oracle database binaries.
  • It provides an alternative to conventional volume managers, file systems and raw devices.

  • Oracle ASM distributes I/O load across all available resource to optimize performance.
  • In this way, it removes the need for manual I/O tuning (spreading out the database files avoids hotspots).
  • Oracle ASM allows the DBA to define a pool of storage (disk groups).
  • The Oracle kernel manages the file naming and placement of the database files on the storage pool.
Disk groups
  • Oracle ASM store data files on disk groups.
  • A disk group is a collection of disks managed as a unit by Oracle ASM.
  • Oracle ASM disks can be defined on:
    • A disk partition: Entire disk or a section of disk that does not include the partition table (or it will be overwritten).
    • A Disk from a storage array (RAID): RAID present disks as Logical Unit Numbers (LUNs).
    • A logical volume.
    • A Network-attached file (NFS): Including files provided through Oracle Direct NFS (dNFS).Whole disks, partitions and LUNs can also be mounted by ASM through NFS.
  • Load balance: Oracle ASM spreads the files proportionally across all of the disks in the disk group, so the disks within a disk group should be in different physical drives.

Disks can be added or removed "on the fly" to and from disk groups.
After you add a disk, Oracle ASM performs rebalancing.
Data is redistributed to ensure that every file is evenly spread across all of the disks.

  • Disks can be added or removed from a disk group while the database is accessing files on that disk group (without downtime).
  • Oracle ASM redistributes contents automatically
  • Oracle ASM uses Oracle Managed Files (OMF).




  • Any Oracle ASM file is completely contained within a single disk group.
  • However, a disk group might contain files belonging to several databases.
  • A single database can use files from multiple disk groups.
Mirroring and Failure groups
  • Disk groups can be configured with varying redundancy levels.
  • For each disk in a disk group, you need to specify a failure group to which the disk will belong.
  • A failure group is a subset of the disks in a disk group, which could fail at the same time because they share hardware
  • Failure groups are used to store mirror copies of data.
  • In a normal redundancy file, Oracle ASM allocates a primary copy and a secondary copy in disks belonging to different failure groups.
  • Each copy is on a disk in a different failure group so that the simultaneous failure of all disks in a failure group does not result in data loss.
  • A normal redundancy disk group must contain at least two failure groups.
  • Splitting the various disks in a disk group across failure groups allows Oracle ASM to implment file mirroring.
  • Oracle ASM implements mirroring by allocating file and file copies to different failure groups.
  • If you do not explicitly identify failure groups, Oracle allocates each disk in a disk group to its own failure group.

Oracle ASM implements one of three redundancy levels:
  • External redundancy:
    • No ASM mirroring. Useful when the disk group contain RAID devices
  • Normal redundancy
    • Oracle ASM implements 2-way mirroring by default.
    • At least 2 failure groups are needed. Minimum of two disks in group.
  • High redundancy
    • Oracle ASM implements 3-way mirroring: Minimum of 3 disks in group




(a) Diskgr1 below implements 2-way mirroring.
Each disk (dasm-d1, dasm-d2) is assigned to its own failure group.
SQL> Create diskgroup diskgr1 NORMAL redundancy
  2  FAILGROUP controller1 DISK
  4     '/devices/diska1' NAME dasm-d1,
  3  FAILGROUP controller2 DISK
  5     '/devices/diskb1' NAME dasm-d1
  6  ATTRIBUTE 'au_size'='4M';



  • An Oracle ASM disk is divided into allocation units (AU).
  • Files within an ASM disk consist of one or more allocation units.
  • Each ASM file has one or more extents.
  • Extent size is not fixed: starting with one allocation unit, extent size increases as total file size increases.



Oracle ASM Instance

Oracle ASM metadata:
  • disks belonging to a disk group
  • space available in a disk group
  • names of files in a disk group
  • location of disk group data extents
  • redo log for changes in metadata blocks
  • Oracle ADVM (ASM Dynamic volume Manager) volume information
  • With Oracle ASM an ASM instance besides the database instance needs to be configured on the server.
  • An Oracle ASM instance has an SGA and background processes, but is usually much smaller than a database instance.
  • It has minimal (how much?) performance effect on a server.
  • Oracle ASM Instances are responsible for mounting the disk groups so that ASM files are available for DB instances.
  • Oracle ASM instances DO NOT mount databases.
  • They only manage the metadata of the disk group and provide file layout information to the database instances.


ASM Instance on Clusetered configurations:
  • One Oracle ASM instance in each cluster node.
  • All database instances in a node share the same ASM instance
  • In a Oracle RAC environment, the ASM and database instances on the surviving nodes automatically recover from an ASM Instance failure on a node.

TCP/IP Networking (I)



TCP/IP Architecture
  • TCP/IP protocol has a four-layer structure linking an application to the physical network.
  • Each layer has its own independent data structures.
  • Conceptually, each layer is speaking directly to its counterpart on the other machine. In this sense, it is ignorant of what goes one after the data is sent.
  • For example, in the Application layer, a NFS Client talks to a NFS Server and knows only the details of the NFS protocol they both use.
  • As data packets are transported from the application to the physical network, each layer adds some control information in the form of a header.
  • Once the packet reaches its destination in the physical network, each layer reads and removes its corresponding header before passing the package up in the stack until it is received by the application.


  • This layer contains all application protocols (often providing user services) that use the Transport layer.
  • Examples of application protocols include FTP, HTTP, DNS, NFS, SMTP, Telnet
  • To send data, the application calls up a Transport layer protocol, such as TCP.
  • Application Layer protocols usually treat transport and lower layer protocols as "black boxes." In this sense, they assume a stable network connection exist across which to communicate.







  • TCP and UDP are the most importan protocols in this layer, delivering data between application and internet layers.
  • TCP provides reliable data delivery service with error detection and error correction. It delivers data received from IP to the correct application (identified by a port number).
  • UPD provides a connectionless delivery service.
  • When called by an application, TCP wraps the data into a TCP packet.
  • A TCP packet (also called TCP segment) contains a TCP header followed by the application data (including header).
  • TCP then hands the packet to IP.
  • TCP keeps track of what data belongs to what process.
  • It is also responsible for ensuring that the packets are delivered with the correct contents and put in the right order before handing them off to the receiving application.

  • The layer above the Network Access layer, and it provides the packet delivery service on which TCP/IP networks are built.
  • It provides a routing mechanism allowing for packets to be transmitted across one or more different networks.
  • The Internet Protocol (IP) runs in this layer and provides a way to transport datagrams across the network.
  • It is a connectionless protocol and does not provide error control, relying on protocols in the other layers to provide error detection and recovery.
  • Source and destination may be in the same or different networks.
  • The IP protocol performs the functions of (a) host addressing and identification, and (b) packet routing (transporting packets from source to destination).
  • After receiving a TCP packet, IP wraps it up and prepends an IP header, creating an IP datagram.
  • Moving the data down the stack, IP hands it off to the hardware driver, that runs in the Network Access Layer.

  • The IP layer has to figure out how to send the packet.
  • Destination on a different physical network ?
    • Then IP needs to find and send it to the appropriate gateway.
  • Destination on the local ethernet network ?
    • IP uses the Address Resolution Protocol (ARP) to determine what Ethernet card's MAC address is associated with the datagram IP address.
  • How does it work?
    • ARP broadcasts an ARP packet across the entire network asking which MAC address belongs to a particular IP address.
    • Although every machines gets this broadcast, only the one out there that matches will respond. This is then stored by the IP layer in its internal ARP table.

You can look at the ARP table at any time by running the command:
jdoe@quark:~$ arp -a
home (194.113.47.147) at 98:0:bd:bd:8c:d2 [ether] on eth0
jdoe@quark:~$ 

  • Protocols in this layer are designed to move packets (IP datagrams) between the internet layer interface of two different hosts on the same physical link.
  • The actual process of moving packets at this level is usually controlled by device drivers of the network cards, which must know the details of the underlying network in order to format the data appropriately.
  • At this level IP addresses are translated to physical addresses used by the network cards (i.e. Media Access Control (MAC) addresses)
  • The network access layer (also called link layer) can be represented by different kinds of physical connections: Ethernet, token-ring, fiber-optics, ISDN, RS-232, etc.

Network Interfaces
  • TCP/IP defines an abstract interface for hardware access.
  • The interface, offering a set of operations that is used to access all types of hardware, hides the implementation details of operations necessary to access each particular equipment. Each vendor is responsible for provinding a driver that translates the commands of the TCP/IP interface to those of the particular piece of hardware.
  • Each networking device has a corresponding interface in the kernel.
  • When configured, each physical device is assigned an interface name.
  • Each interface must also be assigned an IP address. Some interface names include:
    • Ethernet interfaces: eth0, eth1
    • PPP interfaces: ppp0, ppp1
    • FDDI interfaces: fddi0, fddi1
  • A computer having more than one logical or physical network interface is usually called a Multihomed host.

  • An Ethernet network works like a bus system, where a host may send packets (or frames) of up to 1,500 bytes to another host on the same Ethernet.
  • Hosts are identified by a six-byte address hardcoded into the firmware of its Ethernet network interface card (NIC).
  • Ethernet addresses are usually written as a sequence of two-digit hex numbers separated
    by colons, as in aa:bb:cc:dd:ee:ff.

References:
Bautts, Tony, Terry Dawson and Gregor Prudy. 2005. Linux Network Administratos Guide
Hunt, Craig. 2002. TCP/IP Network Administration

Oracle DML Triggers

DML Triggers

DML triggers:
  • Simple
  • Compound
    • can fire at one, some, or all of the preceding timing points
  • INSTEAD OF
    • Created on a noneditioning view, or on a nested table column of a noneditioning view.
    • Used to perform a DML action on the underlying tables of a view.
    • The database fires the INSTEAD OF trigger instead of running the triggering DML statement.
  • Crossedition
    • For use only in edition-based redefinition

  • Triggering event: DELETE, INSERT, and UPDATE.
  • Simple DML trigger fires at exactly one of these timing points:
  • Before the triggering statement runs (BEFORE trigger).
  • After the triggering statement runs (AFTER trigger).
    • Statement triggers are always executed, independently of whether the triggering event actually affected any rows in the underlying table.
    • Statement-level triggers are also known as table-level triggers.
    • You cannot use a WHEN clause in a statement-level trigger.
    • You also cannot reference the new or old pseudo-records in a statement-level trigger. Doing so results in a compile-time error (ORA-04082: NEW or OLD references not allowed in table level triggers).
  • Before each row that the triggering statement affects (BEFORE each row trigger).
  • After each row that the triggering statement affects (AFTER each row trigger).
    • If the DML statement does not affect any row the trigger is NOT executed.

DML Triggers and DCL (Commit, Rollback, Savepoint)
  • You cannot use SQL Data Control Language (DCL) in them, unless you declare the trigger as autonomous.
  • When triggers run inside the scope of a transaction, they disallow setting a SAVEPOINT or performing either a ROLLBACK or COMMIT statement.
  • Also, No function or procedure called by a trigger can have a DCL statement in their execution path.

DML Trigger: Syntax
CREATE [OR REPLACE] TRIGGER trigger_name
 {BEFORE | AFTER}
 {INSERT | UPDATE | UPDATE OF column1 [, column2 [, column(n+1)]] | DELETE}
 ON table_name
 [FOR EACH ROW]
 [WHEN (logical_expression)]
[DECLARE]
  [PRAGMA AUTONOMOUS_TRANSACTION;]
  declaration_statements;
BEGIN
  execution_statements;
END [trigger_name];
/

Trigger firing sequence for any DML (I/U/D)
  1. Before DML FOR EACH STATEMENT.
  2. Before DML FOR EACH ROW.
  3. DML statement executed.
  4. After DML FOR EACH ROW.
  5. After DML FOR EACH STATEMENT.


(?) How many triggers can you have for INSERT on Employees?
  • No restrictions. You can create many for a single event.
  • However, the ORDER of firing is not guaranteed.
  • Consolidate triggers, if sequence in important.

Before UPDATE Statement-level Triggers
  • Useful to ensure integrity rules (i.e. new value should be within some range) or business requirements (i.e. ensure that user has required privileges for operation).
  • Can be also used to check whether the triggering event should be allowed to complete successfully. If the statement is found to be not authorized, the trigger could, for example, log it on an audit table, send notification messages, and raise an exception so that the statement fails.

SQL> CREATE or REPLACE TRIGGER audit_emp_hours
 BEFORE INSERT OR UPDATE OR DELETE 
 ON employees
BEGIN
  IF TO_CHAR (SYSDATE, 'HH24:MI') NOT BETWEEN '08:00' AND '18:00'
        OR TO_CHAR (SYSDATE, 'DY') IN ('SAT', 'SUN') THEN
    RAISE_APPLICATION_ERROR (-20205,
		'You may only make changes during normal office hours');
  END IF;
END;
/
Trigger Created.
SQL> 

SQL> update employees set salary=43000 where employee_id=210;
update employees set salary=43000 where employee_id=210
         *
ERROR at line 1:
ORA-20205: You may only make changes during normal office hours
ORA-06512: at "HR.AUDIT_EMP_HOURS", line 4
ORA-04088: error during execution of trigger 'HR.AUDIT_EMP_HOURS'


Using CONDITIONAL PREDICATES to audit actions/events:
  • INSERING
  • UPDATING
  • DELETING
{ TRUE | FALSE }

The trigger below writes into an audit table (AUDITBL) when any DML statement is executed on the EMPLOYEES table.

(a) Create the Audit table (AUDITBL)

SQL> CREATE TABLE AudiTbl ( 
     id_audit NUMBER  NOT NULL , 
     username VARCHAR2 (20) , 
     action VARCHAR2 (400) , 
     dt_action DATE , 
     table_name VARCHAR2 (100) , 
     old_value VARCHAR2 (400) , 
     new_value VARCHAR2 (400) 
    );
Table created.

SQL>ALTER TABLE AudiTbl 
    ADD CONSTRAINT "AudiTblPK" PRIMARY KEY (id_audit);
Table altered.

SQL> CREATE SEQUENCE seq_audit START WITH 1;
Sequence created.
SQL> 

(b) Create Conditional AFTER UPDATE/INSERT/DELETE Trigger on (EMPLOYEES).

SQL> Set Serveroutput on;

SQL> CCREATE OR REPLACE TRIGGER audit_employees
 AFTER
    INSERT OR
    UPDATE OF salary OR
    UPDATE OF department_id OR
    DELETE
  ON employees
  FOR EACH ROW
BEGIN
  CASE
    WHEN INSERTING THEN
      INSERT into AudiTbl VALUES
       (seq_audit.nextval, user, 'INSERT', sysdate, 'employees', null, null);
      DBMS_OUTPUT.PUT_LINE('Inserting on employees');
    WHEN UPDATING('salary') THEN
      DBMS_OUTPUT.PUT_LINE('Updating salary');
      INSERT into AudiTbl VALUES
       (seq_audit.nextval, user, 'UPDATE salary', sysdate, 'employees', 
        :OLD.salary, :NEW.salary);
    WHEN UPDATING('department_id') THEN
      DBMS_OUTPUT.PUT_LINE('Updating department ID');
      INSERT into AudiTbl VALUES
       (seq_audit.nextval, user, 'UPDATE Dept_id', sysdate, 'employees', 
        :OLD.department_id, :NEW.department_id);
    WHEN DELETING THEN
      DBMS_OUTPUT.PUT_LINE('Deleting');
      INSERT into AudiTbl VALUES
       (seq_audit.nextval, user, 'DELETE', sysdate, 'employees', 
        :OLD.employee_id, null);
  END CASE;
END;
/

Notes:
  • OLD, NEW and PARENT are correlation names. :OLD and :NEW qualifiers can only be used in row level triggers. These reference the old and new values of a column, respectively.







(c) Test the INSERT trigger on (EMPLOYEES).

SQL> insert into employees (employee_id, first_name, last_name, email, 
         phone_number, hire_date, job_id, salary, commission_pct, 
         manager_id, department_id)
values (employees_seq.nextval, 'John', 'Fergunson', 'email@email.com', 
        null, sysdate, 'IT_PROG', 20000, null, null, null);
Inserting on employees

1 row created.
SQL>
SQL> Select * from auditbl;

ID_AUDIT USERNAME ACTION DT_ACTION TABLE_NAME OLD_VALUE NEW_VALUE
1 JOHNF INSERT 18-AUG-10 employees    

(d) Test the UPDATE (salary) trigger

SQL> update employees set salary=salary*2 where employee_id=210;
Updating salary

1 row updated.
SQL>
SQL> Select * from auditbl;

ID_AUDIT USERNAME ACTION DT_ACTION TABLE_NAME OLD_VALUE NEW_VALUE
1 JOHNF INSERT 18-AUG-10 employees    
2 MARCJ UPDATE 11-Sep-10 employees 15000 30000



Row-Level Update Trigger
  • The trigger below is fired when an employee is assigned to the department 10.
  • It fires AFTER an UPDATE on emploees, but ONLY WHEN the update was on the department_id COLUMN AND the new value for that column is set to 10.
  • Note that in the WHEN clause you use NEW. In the trigger bodyyou use :NEW.
  • Inside a trigger body, you preface the pseudo-records with a colon (:). The colon let you reference the externally scoped pseudo-records in the trigger body.

SQL> CREATE OR REPLACE TRIGGER audit_dept10
  AFTER UPDATE OF department_id
  ON employees
  FOR EACH ROW
  WHEN (new.department_id = 10)
BEGIN
  DBMS_OUTPUT.PUT_LINE('Update on employees');
  INSERT into AudiTbl VALUES
    (seq_audit.nextval, user, 'UPDATE', sysdate, 'employees', 
        :old.department_id, :new.department_id);
END;
/

Trigger created.
SQL> set serveroutput on
SQL> update employees 
        set department_id = 10 
        where employee_id in (201, 202, 203, 210);

4 rows updated.
Update on employees
Update on employees
Update on employees
Update on employees

 
SQL> select * from auditbl;



ID_AUDIT USERNAME ACTION DT_ACTION TABLE_NAME OLD_VALUE NEW_VALUE
18 JAFFN UPDATE 26-AUG-11 employees 70 10
18 JAFFN UPDATE 26-AUG-11 employees 20 10
18 JAFFN UPDATE 26-AUG-11 employees 20 10
18 JAFFN UPDATE 26-AUG-11 employees 40 10


Exception handling in Triggers