RAC_Database_Technical_Document

Database Technical Documentation

Last Updated: 11/26/2007 21:35:00 A11/P11

- Confidential - Page 1 of 46

Disclosure and Purpose...............................................................................4Network Configuration..................................................................................5Server Configuration.....................................................................................6

linuxdb01.<SNIPPED>ssc.com...............................................................................................................6General Information:............................................................................................................................ 6Physical Drives.................................................................................................................................... 7Mount Points....................................................................................................................................... 8Logical Volume Devices...................................................................................................................... 8Special directories and files................................................................................................................. 9

Database Instances............................................................................................................................... 11VMFG................................................................................................................................................ 11VQ..................................................................................................................................................... 11PHX................................................................................................................................................... 11HST................................................................................................................................................... 11

Backup Methodology............................................................................................................................. 11Backup Flow...................................................................................................................................... 11Key Backup Scripts........................................................................................................................... 12

Databases..................................................................................................13VQ.linuxdb01.<SNIPPED>ssc.com.......................................................................................................13

Oracle Information............................................................................................................................. 13Instance Information.......................................................................................................................... 13Schema Information.......................................................................................................................... 16Tablespace Information..................................................................................................................... 16Data File Information......................................................................................................................... 17Standby Information..........................................................................................................................17

VMFG.linuxdb01.<SNIPPED>ssc.com..................................................................................................18Oracle Information............................................................................................................................. 18Instance Information.......................................................................................................................... 18Schema Information.......................................................................................................................... 21Tablespace Information..................................................................................................................... 21Data File Information......................................................................................................................... 22Standby Information..........................................................................................................................23

Procedures.................................................................................................24*Linux Procedures................................................................................................................................. 24Basic Oracle Procedures....................................................................................................................... 30Oracle Dataguard Procedures...............................................................................................................40

Appendix.....................................................................................................45RAID Definitions.................................................................................................................................... 45

Document change control...........................................................................46

Last Updated: 11/26/2007 21:35:00 A11/P11


Last Updated: 11/26/2007 21:35:00 A11/P11


DISCLOSURE AND PURPOSEThe purpose of this document is to describe the physical and the logic layout of the Oracle database system used at <SNIPPED> . This document is intended for an audience that is technical with a basic understanding of computers, logic, and scripting.

This document is a living document meaning that it will be constantly updated and changed. It is the responsibility of the reader to ensure that they have the most recent document. To ensure the most recent it is recommended that an electronic document be placed in a master location and all updates be placed with the master document.

Richard ClappSenior Oracle Consultant.

Last Updated: 11/26/2007 21:35:00 A11/P11


NETWORK CONFIGURATIONThe primary database network is consists of two Red Hat Linux servers. The primary server (linuxdb01.<SNIPPED>ssc.com) is located in the computer room located in the “Sales Office” building. The secondary or standby server (linuxdb02.<SNIPPED>ssc.com) is located in the Manufacturing building in the office marked Human Resources. Either the Cisco Aeronet Wireless Bridge and/or the fiber-optic connection between the two buildings connect the two database servers with the standard <SNIPPED> network.

EthernetEthernet

Fiber Optic Cable

EthernetEthernet

Filename: netcfg.vsdCreated: 07/01/03Last Modified: 07/01/03Author: Basil ThompsonDescription: Block diagram of network configurationPage 1of 1

Network Configuration

bridge02192.25.25.23

bridge01192.25.25.43

Antenna Antenna

SalesBuilding

ManufacturingBuilding

Cisco Switch192.25.25.36

Cisco Switch192.25.25.27

linuxdb01.phoenixssc.com192.25.25.158

linuxdb02.phoenixssc.com192.25.25.18

192.25.25.x 192.25.25.x 192.25.25.x 192.25.25.x

Last Updated: 11/26/2007 21:35:00 A11/P11


SERVER CONFIGURATIONThere are two main servers for the current Oracle database structure. The servers are independent of one another and consist of their own operating system and disk array cluster. The servers are setup in a cold-standby method. A cold standby is a set of servers that are physically connected in a cluster but are used to back up one another incase of a failure. In a cold standby configuration, there are two main components, the primary system and the standby system. The primary system is were all the work, computing and transactions are occurring during the course of a normal business day. The standby server or servers are sitting idle waiting for the primary server to fail. At certain intervals, or triggering events, the data is copied from the primary database server to the standby database server. In the event of a failure of the primary server, the standby server can take over operations until all issues have been addressed and/or repairs. The cold standby indicates that the failure switch over does not occur automatically, but intervention from the system administrator needs to happen.

LINUXDB01.<SNIPPED>SSC.COM

Linuxdb01.<SNIPPED> is the primary server at <SNIPPED>. This server is the main Oracle database server and is the home of all the production, test and development databases.

General Information:Hostname: linuxdb01

Domain: <SNIPPED>ssc.comOperating System: Red Hat Enterprise Linux AS 3.0

OS Kernel: 2.4.21-20.0.1.ELhugememCurrent DB Version: 9.2.0.5.0

Oracle Home: /powervault01/u01/oracle/product/9.2.0.5.0TNS Admin: ${ORACLE_HOME}/network/admin

Oracle Admin: ${ORACLE_HOME}/admin

Server Type: Dell PowerEdge 6650 (4-way Xeon 2.4ghz)Installed Memory: 12 GBInternal Storage: 2 – 36 GB Drives (RAID-1 logical)External Storage: Disk Array 1:

Qty 14 73GB Drives (1 RAID-10 logical, 2 hot spares)

Names Server: ns1.<SNIPPED>ssc.comNames Server Port: 9999

IP Address: <snipped>IP Subnet Address: 255.255.255.0Default Gateway: <snipped>Special Routes: <<None>>

Last Updated: 11/26/2007 21:35:00 A11/P11


Physical DrivesEach logical unit of the disk array is formatted and partitioned into file systems.

All the device references are located in the /dev directory and have the following syntax:

/dev/sda1 The /dev signifies that it is a device fileThe /sd signifies that the device is a SCSI Drive.The a signifies that this device is the first logical volume.The 1 signifies that this is first partition of the drive.

Each mount point is pointed to a formatted partition on one of the logical volumes.

/dev/sda and /dev/sdb are located on the internal drives of the server. Linuxdb01 has 4 internal disk units that are setup in a RAID 1 fashion. Devices /dev/sdc through /dev/sdk are located on the two external disk arrays systems.

The following diagram will show the RAID-1 configuration of the disk units (By mount point) in relation to their physical location in the disk array system.

Filename: linuxdb01-raidcfg.vsdCreated: 2005-04-05Last Modified: 2005-04-05Author: Justin SpiesDescription:Block diagram of RAID configurationPage 1of 1

RAID Configuration

Hot

Spa

re

Act

ive

Act

ive

Act

ive

Act

ive

Act

ive

Act

ive/powervault01

(Channel 3)

RAID 1

RAID 0, Controller 1, Channel 0 RAID 0, Controller 1, Channel 1

The system is configured as two mirrored RAID0 arrays, making the trueconfiguration a RAID10 configuration. This entire partition is then setupas a single LVM partition of 544GB

Hot

Spa

re

Act

ive

Act

ive

Act

ive

Act

ive

Act

ive

Act

ive

Last Updated: 11/26/2007 21:35:00 A11/P11


Mount PointsThe following list is the physical mount points of the system:

Device Mount Point Size (M) Description/dev/sda1 /boot 251 Boot Partition – Linux Kernels/dev/sda2 Swap Space 2,047 Swap Space/dev/sda3 / 1,012 Root Partition/dev/sda5 /tmp 2,048 Temporary Directory/dev/sda6 /home 1,012 Home Directories (User Files)/dev/sda7 /var 1,011 Variable system and user files/dev/sda8 /usr 7,697 User level executables and files/dev/sda9 /powervault01/u01 19,116 Oracle Executables and Admin files/dev/sdb1 Swap Space 9,773 Swap Space/dev/sdb2 Logical Volume Group 409,500 /dev/VolGroup01 root

Logical Volume DevicesThe following list is the logical volume mount points of the system. The total capacity of the logical volume is 400GB. Of this amount, currently 262GB is allocated to existing logical volumes, leaving about 147GB of space that can be allocated as needed.

Logical Volume Mount Point Size (M) Description/dev/VolGroup01/redo01 /powervault/u02 32,253 Database Data Files, primarily

redo logs and control files/dev/VolGroup01/redo02 /powervault/u03 32,253 Database Data Files, primarily

redo logs and control files/dev/VolGroup01/archivelogs /powervault/u04 64,507 Database Data Files, primarily

archive logs/dev/VolGroup01/data01 /powervault/u05 129,015 Database Data Files, primarily

data files, dump files and control files

Last Updated: 11/26/2007 21:35:00 A11/P11


Special directories and filesThese directories are important directories and contain special files that are for the operation of the database. Directories with a leading ‘/’ set the root path to which all subsequent entries are added until the next entry with a leading ‘/’ is encountered. For example, the fourth line, below, specifies ‘scripts’ as the entry. The most current entry before that with a leading ‘/’ is ‘/home/oracle/’, a value to which the ‘scripts’ value is appended. This means that the full path for the ‘scripts’ entry is ‘/home/oracle/scripts/’.

Directory Description

/etc/oratabThis file contains all the Oracle instances on the server and their Oracle home locations.

/etc/init.d/onamesThis file is the startup script for the Oracle Names server.

/etc/init.d/oracle

This file is the startup script for the Oracle database system. The databases that are started are determined by the ‘oratab’ file, described above.

/etc/init.d/oralsnr

This file is the startup script for all the Oracle listener instances. Listeners are assumed to have the same name as the database instance to which they belong. In addition, a listener is only started if the associated database is started as well.

/home/oracle/

scriptsLocation of system scripts specific to the user ‘oracle’. Includes the backup/restore scripts necessary to recover a database from an archive.

sql-scriptsLocation of sql script files specific to the ‘oracle’ user, but generic to all database instances.

/powervault01/ u01/oracle/product/ 9.2.0.4.0/network/ SQL*Net and Oracle networking configuration files.

u05/

oradata/SID/Data files for a specific database where SID is one of the database instances listed below.

archivelogs Location of the archive log files.controlfiles Location of the control files.

datafiles Location of the tablespace data files.redologs Location of the online redo log files.

exp Directory to store export files.

admin/Administration and configuration files for each of the database instances.

create Files and scripts used to create the Database.pfile The initialization parameter files.

scripts Special scripts used by the database instance.

standbyFiles used by the database for standby compatibility.

notes Notes and other information for the instance.sql SQL repository for special scripts of the instance.

dumpfiles/ Log files for each of the database instances.adump Administration dump file destination.bdump Background process dump file destination.cdump Core process dump file destination.

Last Updated: 11/26/2007 21:35:00 A11/P11


Directory Description

orabackups/ Files and repositories for the database backups.

hot/SID/Hot backup copies for the database identified by

the SID. Taken nightly, five day retention.

u02 Copy of all data from /powervault/u02/oradata/SID.u04 Copy of all data from /powervault/u04/oradata/SID.u05 Copy of all data from /powervault/u05/oradata/SID.

cold/SID/Cold backup copies for the database identified by

the SID. Taken once each month, two month retention.

exports/ Database export copies, one day retention.

/powervault01/u06/orabackupsSoft link to /powervault/u05/orabackups, provides

storage for copies of all hot and cold backup files.

Last Updated: 11/26/2007 21:35:00 A11/P11


DATABASE INSTANCES

This section will provide an operating system view of the database instances on the server. More detail information about each instance will be provided in the database configuration section of the documentation. Note: The ‘Instance’ name is also the database ‘SID’ value noted in other areas of this document.

Instance RDBMS Ver. Listener Lsnr Port Description

VMFG 9.2.0.5 VMFG 1521Visual Manufacturing Production

VQ 9.2.0.5 VQ 1522Visual Quality Production

PHX 9.2.0.5 PHX 1526<SNIPPED> Acct. Conversion database.

HST 9.2.0.5 HST 1528History database of VMFG before account conversion.

Databases that are highlighted are production databases.

BACKUP METHODOLOGY

The backup methodology of the database service is based on a Disk-to-Disk –to-tape configuration. A disk-to-disk-to-tape configuration states that the databases are backed up to a disk repository then backed up to tape solution. This method allows for complete control of the backups from the database server and is not dependent on the tape solution and drivers.

Backup FlowThe databases are backed up to the /powervault01/u06/orabackup directory. Every evening the /powervault01/u06/orabackup directory is backed up by the tape system using SAMBA technology. SAMBA allows Linux (or UNIX) directories to be mounted from an NT/2000/XP machine as if they were NT share points. This allows the backup program to backup the files from an NT backup software/service.

For additional details regarding the logical flow of the backups, see the document System Backups.vsd

Last Updated: 11/26/2007 21:35:00 A11/P11


Key Backup ScriptsThe backup scripts are divided between the directories /home/oracle/scripts and /home/oracle/sql-scripts. The scripts directory contains the executable shell scripts scripts to provide the nightly and manual backups while the sql-scripts directory contains all supporting SQL command files which are external to the backup scripts themselves.

Script Description Cron entry

coldbackup.sh

Backs up and exports one database (entered as a parameter). Used when a cold backup is required.

To see the help for this script, simply execute the script with no parameters.

(VMFG) 0 18 28 * *(VQ) 30 18 28 * *(PHX) 0 19 28 * *(HST) 30 19 28 * *

hotbackup.shThe main backup script. Backs up and exports all the production databases. Ran every evening by cron.

(VMFG) 0 18 1-27,29-31 * 1-5(VQ) 30 18 1-27,29-31 * 1-5(PHX) 0 19 1-27,29-31 * 1-5(HST) 30 19 1-27,29-31 * 1-5

purgelogs.sh

This backup is used when the archive log destination is getting full. It will perform a backup of all the archive logs and then clear out the archive log destinations.

1 1 28 * *

Last Updated: 11/26/2007 21:35:00 A11/P11


DATABASESThis section is dedicated to the documentation of the databases and their structure any operating system information will be based on the view of the databases. Although descriptions of each database instance and physical attributes will be discussed, only the production databases will be describe in full detail.

VQ.LINUXDB01.<SNIPPED>SSC.COM

VMFG is the main database for the Visual Manufacturing application that is used at <SNIPPED> Specialty. This database is replicated by means of Physical Standby Database. This section will describe the database structure both physically and logically.

Oracle InformationInstance SID: VQGlobal Name: VQ.linuxdb01.<SNIPPED>ssc.comOracle Home: /powervaul01/u01/oracle/product/9.2.0.4.0

Oracle Admin: /powervaul01/u01/oracle/admin/VMFGListener Name: VQ

Listener Address: 192.25.25.158:1522Listener Service Names: VQ.<SNIPPED>ssc.com

VQVQ.linuxdb01.<SNIPPED>ssc.com

TNS Entry: (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.25.25.158)(PORT = 1522))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = VQ.<SNIPPED>ssc.com)))

Names Server Entries: VQ.<SNIPPED>ssc.comVQ.linuxdb01.<SNIPPED>ssc.comVQ_LINUXDB01.<SNIPPED>ssc.com

Instance InformationSGA

Total SGA size: 1,541,190 KbytesFixed Area Size: 442 Kbytes

Variable Area Size: 704,512 KbytesBuffer Cache Size: 835,584 KbytesRedo Buffer Size: 652 Kbytes

Last Updated: 11/26/2007 21:35:00 A11/P11


Non-Default Parameters:

Parameter Name Value Description

audit_trail DB enable system auditingbackground_dump_dest /powervault01/u05/oradata/VQ/dumpfiles/bdump Detached process dump directory

compatible 9.2.0.0.0Database will be completely compatible with this software versio

control_files /powervault01/u02/oradata/VQ/controlfiles/VQ.control.01.ctl control file names list /powervault01/u03/oradata/VQ/controlfiles/VQ.control.02.ctl

/powervault01/u04/oradata/VQ/controlfiles/VQ.control.03.ctl/powervault01/u05/oradata/VQ/controlfiles/VQ.control.04.ctl

core_dump_dest /powervault01/u05/oradata/VQ/dumpfiles/cdump Core dump directorydb_block_size 8192 Size of database block in bytes

db_cache_size 855638016Size of DEFAULT buffer pool for standard block size buffers

db_domain <SNIPPED>ssc.comdirectory part of global database name stored with CREATE DATABA

db_files 500 max allowable # db files

db_name VQdatabase name specified in CREATE DATABASE

dispatchers (PROTOCOL=TCP) (SERVICE=VQXDB)fast_start_mttr_target 300

global_names TRUEenforce that database links have same name as remote database

hash_join_enabled TRUE

java_pool_size 83886080large_pool_size 8388608

job_queue_processes 3 number of job queue slave processeslocal_listener (address=(protocol=tcp)(host=linuxdb01)(port=1522)) local listener

log_archive_dest_1LOCATION=/powervault01/u04/oradata/VQ/archivelogs MANDATORY

archival destination #1 text string

log_archive_format VQ.%t.%s.arch archival destination format

log_archive_start TRUEstart archival process on SGA initialization

max_dump_file_size 20480 Maximum size (blocks) of dump file

open_cursors 2000 max # cursors per session

parallel_max_servers 16maximum parallel query servers per instance

parallel_min_servers 4minimum parallel query servers per instance

Last Updated: 11/26/2007 21:35:00 A11/P11



pga_aggregate_target 434110464Target size for the aggregate PGA memory consumed by the instanc

processes 750 user processes

query_rewrite_enabled FALSEremote_login_passwordfile EXCLUSIVE

session_cached_cursors 200number of cursors to save in the session cursor cache

sessions 750

sga_max_size 1573741824shared_pool_size 268435456 size in bytes of shared pool

sort_area_size 524288star_transformation_enabled FALSE maintain internal timing statistics

timed_statistics TRUE maintain internal timing statisticsundo_management AUTO instance runs in SMU mode if TRUE

undo_retention 900duration for which undo information is kept, in seconds

undo_tablespace ROLLBACK_DATA use/switch undo tablespace

user_dump_dest /powervault01/u05/oradata/VQ/dumpfiles/udump User process dump directory

Last Updated: 11/26/2007 21:35:00 A11/P11


Schema Information

A schema is a logical grouping of database objects such as tables, views, indexes and procedures. Using schema’s allows for the separation of objects based on their application. With the exception of PUBLIC by default, a schema is unable to view the data of another schema unless certain grants or permissions are assigned on the objects.

The table below describes the schemas (users) in the database that contains database objects and a description of their purpose in the production environment.

Schema Name DescriptionDBSNMP The Oracle Enterprise Manager SNMP Agent’s objectsIQS <SNIPPED> Specific OUTLN Internal Oracle User AccountPUBLIC Objects of the database that are available to all usersREPADMIN Internal Oracle Account not used at <SNIPPED>SYS Oracle system tables – do not manipulateSYSADM Visual Quality’s database objectsSYSTEM Oracle Internal Account

Tablespace Information

A tablespace is a logical grouping of database segments such as tables, clusters, and indexes. Splitting the database up into tablespace allows for the separation of database objects with their functionality or location on the disk drives. Each tablespace consists of one or more data files. A data file, however, can only belong to one tablespace. When the database administrator creates an object such as a table he/she provides which tablespace the object is to reside. This indicator tells the database which data files it can use to store the data. An object is not allow to span multiple databases.

The table below describes the tablespace attached to the database and their specific functions.

Tablespace Name DescriptionGENERAL Contains general application data, including tables, views,

synonyms and other entitiesGENERALINX Contains general application indexesROLLBACK_DATA Rollback segmentsSYSTEM System objectsTEMPORARY_DATA Temporary tablespace used for sorting

Last Updated: 11/26/2007 21:35:00 A11/P11


Data File InformationData files are the physical disk files that are used to store the database information. These files are assigned to tablespaces to help organize the objects and properly spread them on the appropriate disk units. There can be multiple data files in each tablespace, but a data file cannot span multiple tablespaces.

Tablespace Data File Size (MB)

GENERAL /powervault01/u05/oradata/VQ/datafiles/VQ.general.01.dbf 1,024.0

GENERALINX /powervault01/u05/oradata/VQ/datafiles/VQ.generalinx.01.dbf 1,024.0

SYSTEM /powervault01/u05/oradata/VQ/datafiles/VQ.system.01.dbf 500.0

ROLLBACK_DATA /powervault01/u05/oradata/VQ/datafiles/VQ.untodbs.01.dbf 500.0

TEMPORARY_DATA /powervault01/u05/oradata/VQ/datafiles/VQ.untodbs.01.dbf 1024.0

All data files are set to auto-extend as needed to the maximum size of 4096 megabytes. The incremental values are different based on the usage of the data file.

Standby Information

Last Updated: 11/26/2007 21:35:00 A11/P11


VMFG.LINUXDB01.<SNIPPED>SSC.COM

VMFG is the main database for the Visual Manufacturing application that is used at <SNIPPED> Specialty. This database is replicated by means of Physical Standby Database. This section will describe the database structure both physically and logically.

Oracle InformationInstance SID: VMFGGlobal Name: VMFG.linuxdb01.<SNIPPED>ssc.comOracle Home: /powervault01/u01/oracle/product/9.2.0.2.0

Oracle Admin: /powervault01/u05/oradata/VMFG/adminListener Name: VMFG

Listener Address: 192.25.25.158:1521Listener Service Names: VMFG.<SNIPPED>ssc.com

VMFGVMFG.linuxdb01.<SNIPPED>ssc.com

TNS Entry: (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.25.25.158)(PORT = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = VMFG.<SNIPPED>ssc.com)))

Names Server Entries: VMFG.<SNIPPED>ssc.comVMFG.linuxdb01.<SNIPPED>ssc.com

Instance InformationSGA

Total SGA size: 2,819,144 KbytesFixed Area Size: 444 Kbytes

Variable Area Size: 1,179,648 KbytesBuffer Cache Size: 1,638,400 KbytesRedo Buffer Size: 652 Kbytes

Last Updated: 11/26/2007 21:35:00 A11/P11


Non-Default Parameters:


audit_trail DB enable system auditingbackground_dump_dest /powervault01/u05/oradata/VMFG/dumpfiles/bdump Detached process dump directory

compatible 9.2.0.0.0Database will be completely compatible with this software version

control_files /powervault/u02/oradata/VMFG/controlfiles/VMFG.control.01.ctl control file names list

/powervault/u03/oradata/VMFG/controlfiles/VMFG.control.02.ctl/powervault/u04/oradata/VMFG/controlfiles/VMFG.control.03.ctl

/powervault/u05/oradata/VMFG/controlfiles/VMFG.control.04.ctl

core_dump_dest /powervault01/u05/oradata/VMFG/dumpfiles/cdump Core dump directorydb_block_size 8192 Size of database block in bytes

db_cache_size 1677721600Size of DEFAULT buffer pool for standard block size buffers

db_domain <SNIPPED>ssc.comdirectory part of global database name stored with CREATE DATABA

db_files 500 max allowable # db files

db_name VMFGdatabase name specified in CREATE DATABASE

dispatchers '(PROTOCOL=TCP) (SERVICE=VMFGXDB)' specifications of dispatchers

fast_start_mttr_target 300MTTR target of forward crash recovery in seconds

global_names TRUEenforce that database links have same name as remote database

hash_join_enabled TRUE enable/disable hash join

instance_name VMFGinstance name supported by the instance

java_pool_size 83886080 size in bytes of the Java pool

large_pool_size 8388608size in bytes of the large allocation pool

log_archive_dest_1 LOCATION=/powervault/u04/oradata/VMFG/archivelogs archival destination #1 text string

log_archive_dest_state_1 ENABLEarchival destination #1 state text string

log_archive_format VMFG.%t.%s.arch archival destination format

log_archive_start TRUEstart archival process on SGA initialization

job_queue_processes 3 number of job queue slave processes

local_listener (address=(protocol=tcp)(host=linuxdb01)(port=1521)) local listeneropen_cursors 1000 max # cursors per session

Last Updated: 11/26/2007 21:35:00 A11/P11



parallel_max_servers 16maximum parallel query servers per instance

parallel_min_servers 4minimum parallel query servers per instance

pga_aggregate_target 579862528Target size for the aggregate PGA memory consumed by the instanc

processes 750 user processes

query_rewrite_enabled FALSEallow rewrite of queries using materialized views if enabled

remote_login_passwordfile EXCLUSIVE password file usage parameter

replication_dependency_tracking FALSEtracking dependency for Replication parallel propagation

session_cached_cursors 200number of cursors to save in the session cursor cache

sessions 830 user and system sessionssga_max_size 2726297600 max total SGA size

shared_pool_size 1048576000 size in bytes of shared poolstar_transformation_enabled FALSE enable the use of star transformation

timed_statistics TRUE maintain internal timing statisticsundo_management AUTO instance runs in SMU mode if TRUE

undo_tablespace ROLLBACK_DATA use/switch undo tablespace

user_dump_dest /powervault01/u05/oradata/VMFG/dumpfiles/udump User process dump directory

Last Updated: 11/26/2007 21:35:00 A11/P11


Schema Information

A schema is a logical grouping of database objects such as tables, views, indexes and procedures. Using schema’s allows for the separation of objects based on their application. With the exception of PUBLIC by default, a schema is unable to view the data of another schema unless certain grants or permissions are assigned on the objects.

The table below describes the schemas (users) in the database that contains database objects and a description of their purpose in the production environment.

Schema Name DescriptionDBSNMP The Oracle Enterprise Manager SNMP Agent’s objectsOPS$ORACLE This user is used for OS level login such as UNIX scriptingOUTLN Internal Oracle User Account<SNIPPED> <SNIPPED> specific tables and data used by all programsPUBLIC Objects of the database that are available to all usersRMANCAT RMAN CatalogSPOTLIGHT Schema to hold objects for ORIX, Inc.’s Monitoring toolSTOCKSEARCH <SNIPPED> Support System’s ObjectsSYS Oracle system tables – do not manipulateSYSADM Visual Manufacturing’s database objectsSYSTEM Oracle Internal AccountTOAD Used by the TOAD monitoring and maintenance applicationUPSWS1 UPS packaging and shipping program

Tablespace Information

A tablespace is a logical grouping of database segments such as tables, clusters, and indexes. Splitting the database up into tablespace allows for the separation of database objects with their functionality or location on the disk drives. Each tablespace consists of one or more data files. A data file, however, can only belong to one tablespace. When the database administrator creates an object such as a table he/she provides which tablespace the object is to reside. This indicator tells the database which data files it can use to store the data. An object is not allow to span multiple databases.

The table below describes the tablespace attached to the database and their specific functions.

Tablespace Name DescriptionINDEX_DATA Indexes used by Visual Manufacturing and <SNIPPED> Support

SystemOEM_CHANGE Oracle Enterprise Manager Change Management Module<SNIPPED>_DATA Special data tables to store <SNIPPED> specific dataRMAN_DATA Recovery Manager (RMAN) segmentsROLLBACK_DATA Rollback segmentsSYSTEM System objectsTEMPORARY_DATA Temporary tablespace used for sortingUSER_DATA Tables used by Visual Manufacturing and <SNIPPED> Support System

Last Updated: 11/26/2007 21:35:00 A11/P11


Data File InformationData files are the physical disk files that are used to store the database information. These files are assigned to tablespaces to help organize the objects and properly spread them on the appropriate disk units. There can be multiple data files in each tablespace, but a data file cannot span multiple tablespaces.

Tablespace Data File Size INDEX_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.index_data.01.dbf

/powervault01/u05/oradata/VMFG/datafiles/VMFG.index_data.02.dbf 2,048.0 2,048.0

OEM_CHANGE /powervault01/u05/oradata/VMFG/datafiles/VMFG.oem_chage.10.dbf 50.0

<SNIPPED>_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.<SNIPPED>_data.01.dbf 2,048.0

RMAN_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.rman_data.01.dbf 50.0

SYSTEM /powervault01/u05/oradata/VMFG/datafiles/VMFG.system.01.dbf/powervault01/u05/oradata/VMFG/datafiles/VMFG.system.02.dbf

2,048.0 2,048.0

ROLLBACK_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.untodbs.01.dbf 1,024.0

USER_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.user_data.01.dbf/powervault01/u05/oradata/VMFG/datafiles/VMFG.user_data.02.dbf

2,048.0 2,048.0

TEMPORARY_DATA /powervault01/u05/oradata/VMFG/datafiles/VMFG.temp.01.dbf/powervault01/u05/oradata/VMFG/datafiles/VMFG.temp.02.dbf/powervault01/u05/oradata/VMFG/datafiles/VMFG.temp.03.dbf

2,048.0 2,048.0

2,048.0

All data files are set to auto-extend as needed to the maximum size of 8192 megabytes. The incremental values are different based on the usage of the data file.

Last Updated: 11/26/2007 21:35:00 A11/P11


Standby Information

Last Updated: 11/26/2007 21:35:00 A11/P11


PROCEDURES

*LINUX PROCEDURES

RAID stands for Redundant Array of Independence Disks which basically states that a RAID is a group of disks that are independently controlled but are working together to either improve the speed, integrity or both. There are many different types of RAID systems and each have a benefit and a cost to them. At <SNIPPED> only a couple of RAID configurations are used.

Server Startup and Shutdown

The current server has been configured to automatically start and stop all necessary Oracle and related support services.

System Startup (Primary Server Only)If the server has entered a shutdown state, either because of intentional power off, UPS shutdown or other, unintended shutdown, the system simply needs to be powered on in order to restart all services.

In the event that there are issues with any of the processes, the Oracle processes can be manually restarted with the following commands:

• Oracle Names Serverservice onames start

-- or -- /etc/init.d/onames start

• Oracle Listenersservice oralsnr start

-- or -- /etc/init.d/oralsnr start

• Oracle Databasesservice oracle start

-- or -- /etc/init.d/oracle start

System Shutdown (Primary Server Only)Shutting down the server is a straightforward task. The first step is to login as the user ‘root’ using either the console or SSH. After successfully logging into the system, use the following Linux command:

[root@pe6650 VMFG]# shutdown now -h

Just as system startup will automatically start the Oracle processes (databases, listeners and Oracle Names server), a system shutdown will automatically shutdown any running Oracle processes. The above command instructs the server to shutdown, immediately, and the halt (turn itself off.) This ensures that all data is written to disk and all processes have stopped running.

Last Updated: 11/26/2007 21:35:00 A11/P11


Logical Volume Manager (LVM)

The Oracle server, linuxdb01.<SNIPPED>ssc.com, has been configured to use LVM as the disk management system underneath the ext3 filesystem.

This configuration provides the flexibility to bring online new partitions, dynamically, without shutting down the server and it provides the ability to increase the size of an existing partition that runs out of space. (This operation, however, is not dynamic in RedHat Enterprise Linux 3. It requires that the partition be changed using LVM and the server be restarted in single user mode so that the file system can be reconfigured while un-mounted. It is highly recommended that a backup be taken before this is done.)

Logical Volumes consist of three different entities. They are:Physical Volume (PV): these are the basic LVM file system and are equivalent to the physical disks in a RAID array

Volume Groups (VG): a group of one or more Logical Volumes, basically the same as the logical drive created when using RAID

Logical Volumes (LV): these are equivalent to the partitions that normally exist inside of a logical RAID drive and are the entity on which the file system is created

Physical VolumesThere currently exists only a single Physical Volume (PV) has been initialized and it resides on the partition /dev/sdb2 (which is about 410GB in size.)

To view the details of the PV on /dev/sdb2, use the pvdisplay command as follows:

[root@pe6650 VMFG]# pvdisplay /dev/sdb2--- Physical volume ---PV Name /dev/sdb2VG Name VolGroup01PV Size 399.90 GB [838657260 secs] / NOT usable 4.56 MB [LVM: 527 KB]PV# 1PV Status availableAllocatable yesCur LV 4PE Size (KByte) 4096Total PE 102374Free PE 36838Allocated PE 65536PV UUID T8n0dh-5gmo-XMbe-VheY-wnhH-rhM4-X81Ai1

The key information above is the PV name or device (in this case /dev/sdb2), the name of the VG assigned to this PV (in this case VolGroup01) and the size of the PV (approximately 400GB.) Also of importance is the statistics on the Physical Extents (PE) of the PV. If you think of a PV as a phone book, the extents are the pages in the book. An extent is an area in the PV on which information can be written and read. The PE size defines how much information each PE can store and is configurable at the time the PV is created. In the above example, each PE is 4096Kbyte (or 4MB). 102374 PE’s exist on the above PV, of which 65536 have been allocated and 36838 are still available. This tells us that (65536 * 4MB) = 256GB has been allocated and is in use, leaving about 144GB available for later use.

To create a new PV, use the pvcreate command as follows:

[root@pe6650 VMFG]# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created

The above command initializes a physical device (/dev/sdb2) as a new Physical Volume for use by the Logical Volume Manager.

Last Updated: 11/26/2007 21:35:00 A11/P11


To remove a new PV, use the pvremove command as follows:

[root@pe6650 VMFG]# pvremove /dev/sdb2 Labels on physical volume "/dev/sdb2" successfully wiped

Volume GroupsOn top of the Physical Volume is the Volume Group. The Volume Group is a collection of one or more Physical Volumes that are allocated to a specific group. This design enables additional PV’s to be created and then, using vgextend, those new PV’s can be added to an existing VG or a new VG can be created. By adding additional PV’s to an existing VG, the additional space can be used to increase the size any existing LV’s or it can be used to create new LV’s in the existing VG.

To display the details of the VG, use the vgdisplay command:

[root@pe6650 VMFG]# vgdisplay--- Volume group ---VG Name VolGroup00VG Access read/writeVG Status available/resizableVG # 0MAX LV 256Cur LV 4Open LV 4MAX LV Size 255.99 GBMax PV 256Cur PV 1Act PV 1VG Size 399.90 GBPE Size 4 MBTotal PE 102374Alloc PE / Size 65536 / 256 GBFree PE / Size 36838 / 143.90 GBVG UUID q7smJE-T3op-25gq-pIXI-VJn1-BxGG-3KhkQ2

--- Volume group ---VG Name VolGroup01VG Access read/writeVG Status available/resizableVG # 0MAX LV 256Cur LV 4Open LV 4MAX LV Size 255.99 GBMax PV 256Cur PV 1Act PV 1VG Size 399.90 GBPE Size 4 MBTotal PE 102374Alloc PE / Size 65536 / 256 GBFree PE / Size 36838 / 143.90 GBVG UUID q7smJE-T3op-25gq-pIXI-VJn1-BxGG-3KhkQ2

In the above listing, the Volume Group Name, Access type, Status, Size and other statistics are readily available. Running the above command with no arguments will display the details for all available Volume Groups. To see the details for a specific Volume Group, spcecify the VG Name as a command line argument:

[root@pe6650 VMFG]# vgdisplay VolGroup01--- Volume group ---VG Name VolGroup01VG Access read/writeVG Status available/resizableVG # 0MAX LV 256

Last Updated: 11/26/2007 21:35:00 A11/P11


Cur LV 4Open LV 4MAX LV Size 255.99 GBMax PV 256Cur PV 1Act PV 1VG Size 399.90 GBPE Size 4 MBTotal PE 102374Alloc PE / Size 65536 / 256 GBFree PE / Size 36838 / 143.90 GBVG UUID q7smJE-T3op-25gq-pIXI-VJn1-BxGG-3KhkQ2

To create a new VG, use the vgcreate command:

[root@pe6650 VMFG]# vgcreate VolGroup01 /dev/sdb2 Volume group "VolGroup01" successfully created

In the example above, a new VG called ‘VolGroup01’ is created using all available space on the Physical Volume /dev/sdb2. It is possible to setup a Volume Group to be spread across multiple Physical Volumes, however should one of the Physical Volumes fail, the entire Volume Group (and it’s contents) would be destroyed. It is better to increase disk capacity by growing a RAID array as opposed to creating a Volume Group using multiple Physical Volumes.

To remove an existing Volume Group, use the vgremove command:

[root@pe6650 VMFG]# vgremove VolGroup01 Volume group "VolGroup01" successfully removed

Note that a Volume Group will not be removed unless all logical volumes have already been removed. Also, note that running the command vgremove with NO arguments will result in the removal of ALL unallocated (i.e., those which do not contain any Logical Volumes) groups to be removed.

Last Updated: 11/26/2007 21:35:00 A11/P11


Logical VolumesThe Logical Volume (LV) is the top most layer of the LVM hierarchy. The LV is to LVM what the partition is to a normal hard disk. It defines the boundaries on which the file system will be constructed.

To view the details of an existing LV, the lvdisplay command is used as follows:

[root@pe6650 VMFG]# lvdisplay /dev/VolGroup01/archivelogs--- Logical volume ---LV Name /dev/VolGroup01/archivelogsVG Name VolGroup01LV Write Access read/writeLV Status availableLV # 3# open 1LV Size 64 GBCurrent LE 16384Allocated LE 16384Allocation next freeRead ahead sectors 1024Block device 58:2

In the above example, /dev/VolGroup01/archivelogs is the physical device path representing the Logical Volume. The above information shows the LV name, the VG of which it is a member, the status, size, Logical Extents (LE) and other technical details.

To create a new Logical Volume, the lvcreate command is used along with several arguments, described below

[root@pe6650 root]# lvcreate -L1G -ntest VolGroup01lvcreate -- doing automatic backup of "VolGroup01"lvcreate -- logical volume "/dev/VolGroup01/test" successfully created

The above command uses three parameters:-L1G specifies the size of the new LV, where 1G translates to 1 Gigabyte; other possibilities for specifying the size are:

K or k for KilobytesM or m for MegabytesG or g for GigabytesT or t for Terabytes

-ntest sets the name of the new LV where test is the name

To remove an existing Logical Volume, use the lvremove command, described below

[root@pe6650 root]# lvremove /dev/VolGroup01/testlvremove -- do you really want to remove "/dev/VolGroup01/test"? [y/n]: ylvremove -- doing automatic backup of volume group "VolGroup01"lvremove -- logical volume "/dev/VolGroup01/test" successfully removed

The above command takes one basic parameter: the path to the Logical Volume to be removed. In the above example, the Logical Volume ‘test’, accessible as the device /dev/VolGroup01/test, is removed from Volume Group ‘VolGroup01’.

Increasing LVM CapacityThis configuration is not really a protected RAID in that there is no protection if a disk failure should occur. A RAID-0 basically states that the information is to be put on a disk. A one disk RAID-0 is similar to the old DOS configuration, but a RAID-0 can be stripped across many disks to help increase the read-write performance.

Last Updated: 11/26/2007 21:35:00 A11/P11


Job Scheduling

On the majority of Unix systems, the CRON utility is used to schedule jobs that need to occur at regular intervals. The files for CRON are stored in several different locations depending on the purpose of the job.

System Wide CRON Configuration FilesThe system wide configuration for CRON is stored in the file /etc/crontab. The default Linux configuration for this file is to run the jobs listed in the following directories:

/etc/cron.hourly Scripts for jobs that should be run each hour, one minute past the hour/etc/cron.daily Scripts for jobs to be run each day at 4:02AM /etc/cron.weekly Scripts for jobs to be run each week on Sunday at 4:22AM/etc/cron.monthly Scripts for jobs to be run on the first day of each month at 4:42AM

To edit any of the above files, simply use an editor such as vi or pico.

NOTE: It is extremely important that all the lines in this file DO NOT contain a trailing space. This will prevent the job from executing and can be very difficult to troubleshoot because the trailing space is not readily visible.

Use Specific CRON Configuration FilesThere also can exist user specific CRON jobs. User specific cron jobs are maintained in the directory /var/spool/cron with each file being named for the user to which it belongs. Thus, the configuration file for the user ‘oracle’ would be /var/spool/cron/oracle.

To edit user specific CRON configuration files, use the crontab command as follows:[root@pe6650 VQ]# crontab -e -u oracle

The –e specifies edit mode and the –u oracle specifies that the file for the user oracle is to be edited.

Last Updated: 11/26/2007 21:35:00 A11/P11


BASIC ORACLE PROCEDURES

The following section provides some commonly executed Oracle commands and processes necessary to maintain the Oracle database.

Oracle Primary Database StartupStartup of an Oracle primary database is a straight-forward process that is mostly automated. The most important point to remember is that the primary database server should start AFTER the standby database server. This ensures that when the primary database is started, the communications channels will automatically be opened.

If the primary database server is started after the standby database server, the system can still be easily started without any downtime by issuing a few additional commands.

Once the primary database server has been started, if the Oracle system is not running, the system can easily be started by issuing the commands listed below. Note that in order to issue the commands, it is necessary to be logged into the system as the user ‘root’. After logging in, do the following:

[root@pe6650 root]# service oralsnr startStarting oralsnr: [ OK ][root@pe6650 root]# service onames startStarting onames: [ OK ][root@pe6650 root]# service oracle startStarting oracle: [ OK ]

The first command starts the Oracle listeners, which enable the client workstations to communicate with the database.

The second command starts the Oracle Names service, which is used by clients to determine how to connect to the database.

The third command starts the Oracle databases. The actual list of databases that are started is controlled by the file /etc/oratab.

Oracle Standby Database StartupStartup of an Oracle standby database is currently slightly more complicated than the startup of the primary database. This will change, however, once the startup script has been written for the standby database.

Once the standby server has been started and a login prompt is available, login to the system as the user ‘oracle’. After logging in, the command prompt will be displayed. To start the standby database, start the SQL Plus command line client on the server:

[oracle@pe6650 VMFG oradata]$spn

SQL*Plus: Release 9.2.0.5.0 - Production on Fri Aug 19 10:37:48 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL>

Review the command prompt since it contains important information. In the above example, the command prompt shows (in order) that the current user is ‘oracle’, the server name is ‘pe6650’, the current Oracle database that will be managed is ‘VMFG’ and the current directory is the ‘oradata’ directory.

Last Updated: 11/26/2007 21:35:00 A11/P11


To start the standby server, connect to the database and tell the system to start the database using a specific initialization file. The initialization file used depends on the database being started. Sticking with the above example, the VMFG database will be started.

SQL> CONNECT SYS/[PASSWORD] AS SYSDBA;Connected.SQL> startup nomount pfile=’/powervault01/u05/oradata/VMFG/admin/pfile/initVMFG-sas.ora’;...

In the example above, the VMFG database is started. Each database is stored in it’s own directory and the files for that database will often include the database name in the file name. For the above command, to start the database APPLE, the following command would instead be used:

SQL> startup nomount pfile=’/powervault01/u05/oradata/APPLE/admin/pfile/initAPPLE-sas.ora’;

Note that the database still is not quite ready to be used as a standby system. It is necessary to tell the system to ‘mount’ the database (so that it can read and write to the files) and the tell the system to begin operating in ‘recovery’ or standby mode.

To mount the database, the following command is done:SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Database altered.

SQL>

After being returned to the SQL command prompt, configure Oracle to start the standby mode, waiting for data from the primary database server:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> QUIT...[oracle@pe6650 VMFG oradata]$

It is important to include all of the command as displayed, above. Once the database returns to the SQL command prompt, that particular database is now running as a standby database. It is safe to exit the SQL Plus utility and start the process for the next database.

Above is documented that the command line shows the current database being managed. In order to start the next database, it is necessary to change the database being managed. Doing so is an easy command—at the command prompt, simply type the database name and hit enter. This will change the database being managed. For example:

[oracle@pe6650 VMFG oradata]$vq[oracle@pe6650 VQ oradata]$

Running the SQL Plus utility will provide for the management of the VQ database instead of the VMFG database. To start the standby VQ database, simply follow the instructions, above.

Oracle Primary Database ShutdownShutting down the primary database is just as straight forward as starting the database. Again, following the logical sequence of startup, it is important (but not critical) to stop the primary database BEFORE stopping the standby database.

To stop the primary database, login to the server as the user ‘root’ and run the following commands:

[root@pe6650 root]# service oracle stopStopping oracle: [ OK ][root@pe6650 root]# service onames stopStopping onames: [ OK ][root@pe6650 root]# service oralsnr stop

Last Updated: 11/26/2007 21:35:00 A11/P11


Stopping oralsnr: [ OK ]

Note two key differences between the above commands to stop the databases and the previous commands to start the databases. 1) The are executed in the reverse order and 2) the ‘start’ parameter is replaced with a ‘stop’ parameter.

Oracle Standby Database ShutdownShutting down the standby database is just about the opposite of starting the database. Again, following the logical sequence of startup, it is important (but not critical) to stop the primary database BEFORE stopping the standby database.

To stop the primary database, login to the server as the user ‘oracle’ and connect to the database:

[oracle@pe6650 VMFG oradata]$spn

SQL*Plus: Release 9.2.0.5.0 - Production on Fri Aug 19 10:37:48 2005


SQL> CONNECT SYS/[PASSWORD] AS SYSDBA;Connected.

After connecting to the database, stop the managed standby recovery process using the following command:

SQL> alter database recover managed standby database cancel;

Database altered.

SQL>

After stopping the managed standby recovery process, shutdown the database as normal:

SQL> shutdown;ORA-01109: database not open

Database dismounted.ORACLE instance shut down.SQL>

After the database has been shutdown, simply quit the SQL*Plus utility. If additional databases need to be shutdown, make sure to switch to those databases before repeating the above steps.

Parameter File ExportOracle has grown into a flexible and highly configurable software package that includes many different operating parameters. While most of these can be configured on the fly, some can only be set at database startup. In order to facility making changes to startup parameters, the ‘parameter file’ or ‘pfile’ is available.

As part of a thorough disaster recovery and business continuity plan, it is important to periodically export this file. It may also be necessary to export the file when system maintenance is performed. The process of exporting a pfile is done from within the Oracle command interface.

[oracle@pe6650 VMFG oradata]$spn<oracle version text>

SQL> connect sys/[password]@VMFG as sysdba;Connected.SQL> create pfile='/powervault01/u05/oradata/VMFG/admin/pfile/initVMFG-2005-04-21.ora' from spfile;

File created.

Last Updated: 11/26/2007 21:35:00 A11/P11


SQL> quit

In the above example, the system parameters are exported to the file /powervault01/u05/oradata/VMFG/admin/pfile/initVMFG-2005-04-21.ora

The from spfile tells oracle to export the settings from the binary parameter file.

For all ‘pfiles’, the naming convention is to use ‘init’ followed by the database name (in the above example VMFG) followed by the date in the format YYYY-MM-DD and the file extension ‘.ora’.

Note: In order to reduce clutter and possible confusion, only non-default configuration settings are saved to the specified file. So if, out of the hundred plus configuration settings, only ten parameters are not set to default values, then the resulting export file will only contain ten lines. Control File ExportThe ‘Control File’ in Oracle is a key component of the database system. It stores the details about the inner workings of the system, such as the tablespaces contained within the database, the data files comprising each tablespace, details about system backups and more. The control file is a critical system file that needs to be protected. Because of the importance of this system, and because the control file is locked while the database is running, Oracle provides two ways to backup the file. In the first case, the control file is exported verbatim as a binary file; in the second it is exported as a series of SQL commands that can be used to recreate a missing control file (although it will loose most of the historical data when using this method.)

The following commands will create a binary file backup of the control file: [oracle@pe6650 VMFG oradata]$spn

<oracle version text>

SQL> connect sys/[password]@VMFG as sysdba;Connected.SQL> ALTER DATABASE BACKUP CONTROLFILE TO 2> ‘/powervault01/u05/oradata/VMFG/admin/controlfiles/VMFG-2005-07-11.control.ctl’;

File created.

SQL> quit

The next set of commands creates a text file containing the necessary SQL commands to recreate the control file. Again, it is important to note that this will result in a control file that does not contain all of the history and other internal data that a binary control file would:

[oracle@pe6650 VMFG oradata]$spn<oracle version text>

SQL> connect sys/[password]@VMFG as sysdba;Connected.SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

File created.

SQL> quit

Database ExportExporting the databases is easily accomplished using two scripts located in the directory /home/oracle/scripts. The two scripts both server different purposes:

export-all.sh – Used to export the entire database. It is important to note, however, that it does not export ALL objects contained in the SYS schema, which is the reason for the second script.

export-sys.sh – Script that exports only those objects that are owned by the user ‘SYS’. This script was created because not all objects owned by the SYS user are exported when performing a FULL export.

Last Updated: 11/26/2007 21:35:00 A11/P11


Both scripts accept the same command line parameter and that is the name of the database from which the export is created. To export the entire VQ database, the following two commands would be used:

[oracle@pe6650 VMFG scripts]$./export-all.sh VQ

… various export details are displayed ..

[oracle@pe6650 VMFG scripts]$./export-sys.sh VQ

… various export details are displayed ..

Cold BackupA cold backup in Oracle is one that is taken when the database is not in operation. Not in operation means that all users have disconnected from the database and that the database has been properly stopped using the Oracle ‘SHUTDOWN’ command. Because of this, a cold backup is typically taken outside of normal business hours.

In order to ease the cold backup process, a script has been written that performs all necessary steps with the exception of placing a copy of the backup outside of the server from which the backup was taken. This includes the following steps:

1. Listing currently connected users2. Disconnecting all connected users3. Saving the current parameters to a parameter file4. Shutting down the database5. Creating an archive that contains all data files, the current parameter file and a backup copy of the control file6. Restarting the database7. Notifying the database administrator upon completion of the backup

(For details, see the ‘Cold Backup’ tab of the document System Backups.vsd)

To perform a cold backup, perform the following steps:1. Make sure that the backup has been scheduled and approval obtained as the

database must be shutdown2. As the user ‘oracle’, login to the server linuxdb013. Change to the scripts directory:

[oracle@pe6650 VMFG oracle]$cd scripts

4. Start the backup script using the required parameters, described below:[oracle@pe6650 VMFG scripts]$./coldbackup.shUseage: ./coldbackup.sh dbname userid password

Example: ./coldbackup.sh VMFG sys mypassword

When the backup has completed, an email will be sent to those addresses specified in the script. To change the recipients, see the section titled ‘Changing Backup Job Notification Recipients’, below.

In addition to the file /home/oracle/scripts/coldbackup.sh, one additional file is required for the cold backup to work. That file, /home/oracle/scripts/cold-base-exclude.lst, contains a list of files that are to be excluded from the archive created by this backup process. All files that need to be excluded should be listed in this file, which can include wild card formatted names.

The file resulting from the backup process is stored in the directory /powervault01/u05/orabackup/cold/<database name>/ and is named in the following format:

<database name>-yyyy-mm-dd.tar.gz

Last Updated: 11/26/2007 21:35:00 A11/P11


where <database name> is the name of the database (i.e., VMFG, VQ, HST or PHX), yyyy is the current year, mm is the current month and dd is the day of the month on which the backup was started.

Restore of a Cold Backup1. Untar the appropriate file archive onto the file system. For example, to untar the backup taken for

the month of June (all cold backups are currently scheduled to happen once monthly) into the root directory:

tar xzvf VMFG-2005-06-28.tar.gz –C /

(Note that the archive is created from the root of the file system, so it includes the /powervault01 directory)

2. Connect to the database and startup the system:[oracle@pe6650 VMFG docs]$sqlplus /nolog

SQL*Plus: Release 9.2.0.5.0 - Production on Thu Jul 14 08:31:22 2005


SQL> CONNECT SYS/[PASSWORD] AS SYSDBA;Connected.SQL> STARTUP

…

Last Updated: 11/26/2007 21:35:00 A11/P11


Hot BackupWhile a cold backup is one taken after the database has been shutdown, a hot backup is the opposite—the backup is taken while the database is in production. It is because of this feature that Oracle databases can operate in a 24x7 environment.

As with the cold backup process, a script has been written to ensure accurate and consistent backups while the database is in production. The script to be used, hotbackup.sh, also is located in the directory /home/oracle/scripts and is run using the same basic commands and process.

A hot backup is taken using the following process:1. As the user ‘oracle’, login to the server linuxdb012. Change to the scripts directory:

[oracle@pe6650 VMFG oracle]$cd scripts3. Start the script as follows:

[oracle@pe6650 VMFG scripts]$./hotbackup.shUseage: hotbackup.sh dbname userid password

Example: ./hotbackup.sh VMFG sys mypassword

The above will start a hot backup of the VMFG database, connecting as the user SYS and with the password mypassword.

When the backup has completed, an email will be sent to those addresses specified in the script.

In addition to the file /home/oracle/scripts/hotbackup.sh, one additional file is required for the cold backup to work. That file, /home/oracle/scripts/hot-baseinclude.lst, contains a list of only those files that are to be included in the archive created by this backup process. All files that need to be included should be listed in this file, which can include wild card formatted names. Since the program rsync is used to perform the file copy/backup process, see the man page for rsync for details on the include patterns.

The file resulting from the backup process is stored in the directory /powervault01/u05/orabackup/cold/<database name>/ and is named in the following format:

<database name>-yyyy-mm-dd.tar.gz

where <database name> is the name of the database (i.e., VMFG, VQ, HST or PHX), yyyy is the current year, mm is the current month and dd is the day of the month on which the backup was started.

Restore of a Hot Backup1. Create a temporary directory into which the archive will be extracted. Note that the extracted

archive will require between 2GB and 8GB of space.[root@pe6650 oracle]# mkdir tmp[root@pe6650 oracle]# cd tmp

2. Untar the hot backup archive file, for example to restore the VMFG database, use the following command:

[root@pe6650 oracle]# tar xzvf /home/oracle/VMFG-hot-2005-07-13.tar.gz

3. Because of how the script is written, they will be restored to the current directory in the folder./powervault01/u06/orabackup/hot/<dbname>

4. The files above need to be restored to their original locations. Within the directory described in step 3, all files are contained within their respective uxx directories. This means that the directories in ./powervault01/u06/orabackup/hot/VMFG need to be copied to the directory /powervault01/

To copy them back to the original locations on the system, do the following:[root@pe6650 tmp]# cd powervault01

Last Updated: 11/26/2007 21:35:00 A11/P11


[root@pe6650 VMFG]# rsync –avr ./u06/orabackup/hot/VMFG/* /powervault01/

It is a good idea to leave the restored files for now as they may be needed later.

5. Once the above files have completed the copy process, the password and init files need to be restored. These are contained in the directory (relative to the tmp directory created in step 1, above):

./powervault01/u01/oracle/product/9.2.0.4.0

and can be copied using the following command:[root@pe6650 tmp]# rsync –avr ./u01/oracle/product/9.2.0.4.0/* \> /powervault01/u01/oracle/product/9.2.0.4.0/

6. The above creates most, but not all, directories on the server. To create the rest of the directories, locate the file called createdbdirs.sh and edit the file. It should be located in /powervault01 if that is the directory to which the files were copied in step 4, above. Edit the file and look for the following:

ROOTDIR=/tmp

This line needs to be changed so that it points to the new root directory into which the database files are restored. When a disaster has occurred that requires putting the files in their original locations, the value should be set as follows:

ROOTDIR=/powervault01

7. Make sure that the correct permissions are set on the above file by running the following command:[root@pe6650 tmp]#chmod 755 /powervault01/createdbdirs.sh

8. Execute the createdbdirs.sh script in order to create the missing directories. It requires a single parameter—the name of the database for which to create the directories:

[root@pe6650 tmp]#/powervault01/createdbdirs.sh VMFG

9. After having copied the necessary password files, the backup control files need to be restored from the backup contained within the backup set. The control files are stored in the directory

./powervault01/u02/oradata/<<dbname>>/controlfiles/

and use the naming format <<dbname>>.yyyy-mm-dd.control.ctl where <<dbname>> is the database name and yyyy-mm-dd is the date of the backup being restored. For example, if the backup being restored is for the VMFG database and the backup was taken on July 11th, 2005, the file would be called VQ.2005-07-11.control.ctl

The above file needs to be copied to the control file directories as follows:[root@pe6650 tmp]# cd /powervault01/u05/oradata/VMFG/admin/controlfiles

[root@pe6650 controlfiles]# for s in `seq 2 5` > do \> cp VMFG-2005-07-11.control.ctl \> /powervault01/u0${s}/oradata/VMFG/controlfiles/VMFG.control.`expr ${s} – 1`.ctl> done

10. Set the ORACLE_SID environment variable to that of the database which is being restored, for example, to restore the VMFG database, use the following command:

[root@pe6650 orabackup]# export ORACLE_SID=VMFG

11. Start SQL*Plus without logging in[root@pe6650 orabackup]# sqlplus /nolog

12. Connect to an idle instance of the databaseSQL> CONNECT SYS/[PASSWORD] AS SYSDBA;

13. Create the server parameter file to be used by Oracle in starting the database

Last Updated: 11/26/2007 21:35:00 A11/P11


SQL> CREATE SPFILE FROM PFILE=’/powervault01/u05/oradata/VMFG/admin/pfile/initVMFG-pap.ora’;

Note: There are four different parameter files contained within the above directory. Each one has a particular purpose:

pap – Primary as Primary, this file provides the necessary settings to run the primary database server (linuxdb01) as the primary database server

pas – Primary as Standby, this file provides the settings necessary to run the primary database server (linuxdb01) as the standby database server

sap – Standby as Primary, enables the standby database server (linuxdb02, …) to function as the primary server

sas – Standby as Standby, provides the settings needed to run the Standby configuration

14. Start, but do not open, the databaseSQL> STARTUP MOUNT;

15. Apply the archive logs to the databaseSQL> RECOVER AUTOMATIC DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;

16. Open the databaseSQL> ALTER DATABASE OPEN RESETLOGS

17. Add all necessary temporary tablespaces needed in order for the system to operate (for file sizes and data file names, see above)

SQL> ALTER TABLESPACE TEMPORARY_DATA ADD TEMPFILE 2> ‘/powervault01/u05/oradata/VMFG/datafiles/VMFG.temp.01.dbf’ 3> SIZE 4192M;

In the example, above, a data file with an initial size of 4192MB is added to the TEMPORARY_DATA tablespace. To ensure proper file naming and size allocation, make sure to review the database configuration in section xx.xx.xx

18. Create a cold backup using the instructions above (this will also shutdown the database)

19. Restart the database[oracle@pe6650 VMFG docs]$sqlplus /nolog

SQL*Plus: Release 9.2.0.5.0 - Production on Thu Jul 14 08:31:22 2005


SQL> CONNECT SYS/[PASSWORD] AS SYSDBA;Connected.SQL> STARTUP

…

Changing Backup Job Notification RecipientsChanging the recipients is a straight forward task, however it does require editing the script task. Recipients are specified in one of two ways 1) as the direct recipient or 2) as a recipient of a carbon copy of the message.

To change the primary or direct recipient, look for the line labeled “MESSAGE RECIPIENT”. Below this is the line that assigns the recipients, it will be similar to the following:

TO=”[email protected]”

The [email protected] probably will contain a different (and valid) email address. To set the recipient, simply change the email address. Note that it is important to include the leading and trailing double quotes around the email address.

Last Updated: 11/26/2007 21:35:00 A11/P11


mailto:[email protected]


To specify or change the carbon copy recipients, look for the line labeled “CARBON COPY RECIPIENTS”. Several lines below this will be a line similar to the following:

CC=”-c [email protected]”

Again, the [email protected] probably will contain a different (and valid) email address. To set the CC recipient(s), use the following format:

If no CC recipients are desired: CC=””

Specify a single CC recipient: CC=”-c [email protected]”

Specify multiple CC recipients: CC=”-c [email protected],[email protected]”

Note: It is critical this value is ALWAYS defined, even if no CC recipients are desired. Failure to do so could result in a failure of the cold backup. It is equally critical that the value include the leading “-c “ when one or more CC recipients is specified.

Last Updated: 11/26/2007 21:35:00 A11/P11


mailto:[email protected],[email protected]




ORACLE DATAGUARD PROCEDURES

This section details the procedure to perform the failover operation of an Oracle Data Guard system. Data Guard is a server configuration in which one or more standby database systems provide nearline backup server functionality for a primary database server. Should the primary server fail, one of the standby systems can be promoted to take over the functionality previously provided by the primary server.

It is important to note that a fail over operation is to be used when unscheduled downtime of the primary server occurs. If the downtime is due to maintanence that can be scheduled, a switchover should be performed instead (see Standby Server Switch Over)

Failover to Standby ServerTo perform a failover from the Primary database server to the Standby database server, complete the following instructions.1. Identify the parameters on the standby server that must be changed in order to complete the

failover. (Note: These changes only need to be made if the four pre-configured control files are missing. The four control files are the Primary-as-Primary (pap), Primary-as-Standby (pas), Standby-as-Primary (sap) and Standby-as-Standby (sas) files.)

a. Parametersi. Primary Database: Primary Role Initialization Parameters

The following parameters are set when the Standby Database System is first brought online and are maintained while the system is the acting Primary Database System:

LOG_ARCHIVE_DEST_1='LOCATION=/powervault01/u04/oradata/VQ/archivelogs'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_DEST_2='SERVICE=VQ_LINUXDB01 LGWR MANDATORY SYNC AFFIRM REGISTER'LOG_ARCHIVE_DEST_STATE_2=ENABLELOG_ARCHIVE_FORMAT=%d_%t_%s.arcREMOTE_ARCHIVE_ENABLE=TRUE

ii. Primary Database: Standby Role Initialization ParametersThe following parameters are set when the Primary Database System is transitioned from the role of primary to the role of Standby Database System:

FAL_SERVER=VQ_LINUXDB02FAL_CLIENT=VQ_LINUXDB01STANDBY_ARCHIVE_DEST='/powervault01/u04/oradata/VQ/archivelogs'STANDBY_FILE_MANAGEMENT=AUTOREMOTE_ARCHIVE_ENABLE=TRUE

iii. Standby Database: Standby Role Initialization Parameters

The following parameters are set when the Standby Database System is first brought online and are maintained while the system is the acting Standby Database System:

FAL_SERVER=VQ_LINUXDB01FAL_CLIENT=VQ_LINUXDB02STANDBY_ARCHIVE_DEST='/powervault01/u04/oradata/VQ/archivelogs'LOG_ARCHIVE_DEST_1='LOCATION=/powervault01/u04/oradata/VQ/archivelogs'LOG_ARCHIVE_DEST_STATE_1=ENABLELOG_ARCHIVE_FORMAT=%d_%t_%s.arcSTANDBY_FILE_MANAGEMENT=AUTOREMOTE_ARCHIVE_ENABLE=TRUE

iv. Standby Database: Primary Role Initialization Parameters

The following parameters are set when the Primary Database System is transitioned from the role of primary to the role of Standby Database System:

Last Updated: 11/26/2007 21:35:00 A11/P11


LOG_ARCHIVE_DEST_2='SERVICE=VQ_LINUXDB01 LGWR SYNC AFFIRM REGISTER'LOG_ARCHIVE_DEST_STATE_2=ENABLEREMOTE_ARCHIVE_ENABLE=TRUE

NOTE: In the above item, note that MANDATORY is not specified. This is important because the database will not start properly. This is because what was the Primary Database System will now become the Standby Database System and that system is currently offline. Specifying MANDATORY will prevent the new Primary Database System from starting unless another Standby Database System is available.

b. Parameter Changesi. On the Primary Database System, change the parameters listed above in item 1.2.2. This

is assuming that the Primary Database System has returned to operational status. This can easily be done by using the parameter file initVQ-pas.ora, described in the Assumptions section.

ii. On the Standby Database Server, change the parameters listed above in item 1.2.4. This can easily be done by using the parameter file initVQ-sap.ora, described in the Assumptions section.

2. Check for any gaps in the archived redo logs. If any exist, they will need to be reconciled before continuing. The following query and results demonstrate the a gap in the archived redo logs:

SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- -------------- 1 90 92

In the above example the gap comprises archive logs 90, 91, and 92 for thread 1. If possible, copy all of the identified missing archived redo logs to the target standby database from the primary database or from another standby database and register them. This must be done for each thread. Obviously if the Primary Database System had a major hardware failure and is not online, this will not be possible and the data contained within the missing log archives is lost.

3. Check for other missing archived redo logs.Using the following query on all systems (both Primary Database Systems and Standby Database Systems), it is possible to determine which, if any, systems are missing archived redo logs. The way to make this determination is to compare, between each system, the value in the LAST column for each thread. If any differences exist, then the highest number in the LAST column will display the correct value.

SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) 2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;

THREAD LAST---------- ---------- 1 100

4. Initiate the graceful failover process:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

5. Confirm the status of the managed standby processOn the standby server that is to become the new primary server. Use the following query to determine this status:

Last Updated: 11/26/2007 21:35:00 A11/P11


SQL> SELECT PROCESS FROM v$managed_standby;

no rows found

In the above example, the system is ready for standby to primary failover. If this is not the case and some records are returned, then it will be necessary to restart the database in standby mode:

SQL> SHUTDOWN;ORA-01109: database not open

Database dismounted.ORACLE instance shut down.SQL> STARTUP NOMOUNT PFILE='/powervault01/u05/oradata/VQ/admin/pfile/initVQ-sas.ora';ORACLE instance started.

Total System Global Area 1578179308 bytesFixed Size 453356 bytesVariable Size 721420288 bytesDatabase Buffers 855638016 bytesRedo Buffers 667648 bytesSQL> ALTER DATABASE MOUNT STANDBY DATABASE;

Database altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

The reason for the above commands is because if the network connection is interrupted, the RFS (Remote File System) does not always properly shutdown.

Issuing the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH command cannot complete because it causes the ARCH (Archiver) process to read all transactions from the redo logs and archive them. The MRP (Managed Recovery Process) then applies the contents of the archived logs to the database. When the RFS does not shutdown, it keeps open the redo log files, preventing the ARCH process from archiving the logs and thus preventing MRP from applying the archived logs to the database.

Restarting the database forces the release of the logs by the RFS. The ALTER DATABASE RECOVER ... FINISH command can then be issued and will function properly.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Database altered.

6. Convert the Standby Database System to a Primary Database SystemIssue the following commands to failover the database from the Standby system to the Primary system:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;Database altered.

After failing over the Standby Database System to act as the Primary Database System, it is necessary to stop the database and restart it using the Standby as Primary configuration file (i.e. initVQ-sap.ora):

SQL> CREATE SPFILE FROM PFILE='/powervault01/u05/oradata/VMFG/admin/pfile/initVMFG-sap.ora';

File created.

Last Updated: 11/26/2007 21:35:00 A11/P11


SQL> startupORACLE instance started.

Total System Global Area 2500927292 bytesFixed Size 454460 bytesVariable Size 1207959552 bytesDatabase Buffers 1291845632 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL>

7. Reconfigure the network interfacesNow that the Primary database is again running, it is necessary to reconfigure the network interfaces on the new Primary database so that it now communicates using the IP address of the Primary database system.

The next several steps need to be completed while logged into the system as the user ‘root’.

a. Connect to the primary IP address of the standby server and login as the user ‘root’.b. Start the secondary network interface on the standby server:

[root@pe6450 root]# ifup eth0

c. Connect to the secondary IP address, 192.25.25.18, for the standby server. This is necessary because the primary address is going to be shutdown.

d. Shutdown the existing network interface (make sure to shutdown the appropriate interface):

[root@pe6450 root]# ifdown eth2

e. Copy the Primary database server network interface configuration file from the backup location as the current system network configuration file:

[root@pe6450 root]# cp /root/standby-database/ifcfg-eth2-primary \> /etc/sysconfig/network-scripts/ifcfg-eth2

f. Start the network interface using the Primary database server IP address:

[root@pe6450 root]# ifup eth2

g. Make sure that the updated primary IP address on the Standby database server is functioning correctly. This can be done by connecting to the server ‘linuxdb01’ using SSH. After logging in, confirm that the command line displays the hostname ‘pe6450’:

[root@pe6450 root]#

8. Start the Oracle Names serviceIn order to resolve database connection specifics, Oracle traditionally has relied on the Oracle Names service. While this service is being replaced by the Oracle Internet Directory, it still is in use at <SNIPPED> Specialty. Because of this, it needs to be started on the Standby database server in order for all systems to properly function.

To start the Oracle Names service, do the following while logged in as the ‘oracle’ user:

[root@pe6450 tmp]# service onames start

Last Updated: 11/26/2007 21:35:00 A11/P11


9. Restart the Oracle ListenersOracle Listeners enable network communications by listening for incoming TCP/IP based database communications. The standard listeners on the Standby database server listen specifically for Standby database communications. This is done to prevent any accidental communications.

To restart the Oracle Names service, do the following while logged in as the ‘oracle’ user:

[oracle@pe6450 oracle]# service oralsnr start

Last Updated: 11/26/2007 21:35:00 A11/P11


APPENDIX

RAID DEFINITIONS

RAID stands for Redundant Array of Independence Disks which basically states that a RAID is a group of disks that are independently controlled but are working together to either improve the speed, integrity or both. There are many different types of RAID systems and each have a benefit and a cost to them. At <SNIPPED> only a couple of RAID configurations are used.

RAID-0 (Stip Only) – This configuration is not really a protected RAID in that there is no protection if a disk failure should occur. A RAID-0 basically states that the information is to be put on a disk. A one disk RAID-0 is similar to the old DOS configuration, but a RAID-0 can be stripped across many disks to help increase the read-write performance.

RAID-1 (Mirrored) – A RAID-1 configuration means that all the contents of one disk are mirrored onto a disk of equal size. RAID-1 is a costly method because the information of one disk is completely copied to another disk of the same size and speed. A RAID-1 also requires that each write happen to the number of disks that are being mirrored. This double writing can reduce the performance of the write throughput. The main benefit of a RAID-1 is that when there is a failure all the information is available to the system and no calculations are required in determine the missing data. Another benefit of a RAID-1 is that the each disk in the configuration is a copy and the system can be aware of this. This is beneficial because when there are two or more read request for the same disk unit the OS can send a request to each drive knowing that they contain the same information.

RAID-5 (Stripped with Parity) – A RAID-5 provides the highest level of protection for any system at the lowest dollar costs. A RAID-5 is a configuration in which all the data in a data block are stripped across 3 or more independent platters; along with enough information (parity bit) to be useful if a drive fails. When a drive fails the system is able to determine what the missing information is based on the working disks and the parity information. RAID-5 provides the highest protection of the data at the lowest dollar cost per megabyte. However, by design all writes to the RAID-5 requires that data be written to all drives, and the parity (double-write) occurs which significantly increases the amount of data being written and the performance of the data. While the protection of the data is high at a low cost, if a failure should occur a mass slow down of reads will be experiences since the system will have to calculate what the missing data is from the parity information.

Last Updated: 11/26/2007 21:35:00 A11/P11


DOCUMENT CHANGE CONTROL

Version Date Author Notespre1.0 07/14/03 Bryan Lenihan First Draft of the document1.0 2005-04-05 Justin Spies Updated to match new linuxdb01 server1.1 2005-07-13 Justin Spies Updated database configuration details;

added hot and cold backup information1.2 2005-08-26 Justin Spies Added the sections for Standby database

startup, shutdown and failover.

Last Updated: 11/26/2007 21:35:00 A11/P11


Date post:	18-Jul-2015
Category:	Documents
Upload:	richard-clapp
View:	62 times
Download:	0 times

RAC_Database_Technical_Document

Documents