Wednesday, October 10, 2012

How to configure the IBM storage subsystem to achieve the best performance and availability possible

  • Designate a hot spare disk drive in each expansion drawer.
  • Create a RAID 10 array across as many disk drives as possible
  • Create a logical drive that is two-thirds the capacity of the RAID 10 array
  • Set the stripe size to 512 KB for each logical drive. The 512 KB stripe size provided
    the best results in IBM testing using the ORION utility
  • Change cache settings on the logical drive
  • Disable dynamic cache read prefetch.
  • Map the logical drive to the host system
If you are considering or implementing an Enhanced Remote Mirroring solution, segment the data structure to the smallest size necessary. Small segments limit the amount of data to be transferred across the WAN links

Do not multiplex to the same disk drive

Multiplexing to the same disk drive introduces twice the amount of I/O to the disk drive. Also, no
redundancy exists in case of failure or corruption of the disk drive

Tuesday, October 2, 2012

How to move lobsegment and lobindex to a different Tablespace

You can move a LOBSEGMENT with the

ALTER TABLE owner.table_name MOVE LOB (column_name) STORE AS (tablespace_name)

You cannot specify a tablespace for the LOBINDEX -- it is automatically created and moved with the LOBSEGMENT.

The mapping between a Table's LOB column and it's LOBSEGMENT (or vice versa , if you start with a LOBSEGMENT and want to know which Table it belongs to) is ALL/DBA/USER_LOBS where
table_name and column_name are available with segment_name. You can even identify the LOBINDEX from index_name in the same view.

Note : "small" LOBs stored inline (ie in the row itself) are not in a seperate LOBSEGMENT at all. That is called STORAGE IN ROW and is the default for LOBs of 4000bytes or less.

Monday, October 1, 2012

Why you should use Oracle RMAN for backups and recovery

  • You can take advantage of the powerful Data Recovery Advisor feature, which enables
    you to easily diagnose and repair data failures and corruption
  • There are simpler backup and recovery commands
  • It automatically manages the backup files without DBA intervention
  • It automatically deletes unnecessary backup datafiles and archived redo log files both
    from disk and tape
  • It provides you with detailed reporting of backup actions
  • It provides considerable help in duplicating a database or creating a standby database
  • It lets you test whether you can recover your database, without actually restoring data
  • It lets you verify that available backups are usable for recovery
  • It lets you make incremental backups, which isn’t possible by any other means of
  • It lets you perform database duplication without backups by using the network-enabled database duplication feature, also known as active duplication
  • It automatically detects corrupt data blocks during backups, with the corruption rele-vant information recorded in the V$DATABASE_BLOCK_CORRUPTION view
  • When only a few data blocks are corrupted, you can recover at the data block level,
    instead of recovering an entire datafile
  • You can take advantage of the unused block compression feature, wherein RMAN skips
    unused data blocks during a backup
  • Only RMAN provides the ability to perform encrypted backups
  • You can use RMAN with a variety of third-party storage systems
  • You can use a powerful yet easy-to-use scripting language, which lets you write custom
    backup and recovery scripts quickly