VERITAS Database Edition for Oracle Erik Möller Solutions Marketing Manager, EMEA

Agenda VERITAS Overview Database Edition for Oracle Architecture Enhanced Performance High Availability Faster Recoverability Summary

What We Do VERITAS Intelligent Storage Software for a Digital Economy Ability to Execute Power to Change

Market Strength World’s Largest Storage Software Company Dataquest May 2001 Top 10 Largest Software Companies by Revenue ~$4 Billion R&D Spending R&D Spending (over next 5 years) 5,000+ Employees 5,000+ Employees Deployed in 103 Offices Worldwide $1.6B Annualized Revenue ~ US $29 Billion MarketCapitalization

Digital Freedom CRMMessagingERP Internet Applications Financial Applications High Availability Data Protection SAN Disaster Recovery SUN EMC HP IBM HITACHI COMPAQ DELL FUJITSU NEC SolarisHP-UX Windows NT AIX Linux

Storage Software Architecture F o u n d a t i o n S u i t e N e t B a c k u p E d i t i o n s V o l u m e R e p l i c a t o r Hot & Cold Backups Block Level Incremental Backups Storage Checkpoints Asynchronous Replication Synchronous Replication LAN Clustering WAN Clustering C l u s t e r S e r v e r S a n P o i n t C o n t r o l Global Clustering Business Continuance Low Level SLAMedium Level SLAHigh Level SLA INVESTMENT AVAILABILITY VAI Journaled File System Redundancy Data

Database Edition for Oracle Features

VERITAS Database Edition for Oracle: Improves Oracle performance by 200% Virtually eliminates database backup window Speeds database recovery Improved Availability and Manageability through Storage Virtualization Certified solution by Oracle

Enhanced Performance

Raw Disk or File System? 70-80% of databases are run on raw disks or conventional file systems Manageability  “Invisible” locations for tablespaces  Difficult to grow tablespaces Database Edition for Oracle Performance  Best OLTP performance Data Reliability  No potential for data loss with data written to disks directly DisadvantagesAdvantages Raw Disks Performance  Lower database throughput (30-90% of raw disk)  Higher CPU overhead Data Reliability  Potential data loss Advantages Manageability  Tablespace organization  System-wide backup and restore policies  Easy to create and expand files for Oracle Disadvantages Conventional File Systems

VERITAS Virtualization Platform Combine disk space from multiple arrays Increase / decrease volumes online Mirror data between arrays Common GUI Virtualize disk Disk subsystem Control Logic (Controller) Control Logic (Controller) Virtual disks Host computer Control logic (volume manager)

Increase Performance 200% Quick I/O - Break-through VERITAS File System interface technology The Quick I/O functionality eliminates traditional UNIX file system overhead Presents regular VERITAS File System files to Oracle as Quick I/O devices Allows parallel updates to database files for increased throughput VERITAS File System regular file Quick I/O device Oracle Server

Database Performance Issues with Conventional File Systems Redundant data buffering System buffer cache Database buffer cache Single writer lock per file at UNIX file system level UNIX file-level lock RDBMS row- or page-level lock Kernelized asynchronous I/O (KAIO) Supported only on raw

VERITAS Cached Quick I/O Why Cached Quick I/O? 4 GB max on Oracle buffer cache Large System memory often unused Current solution: Traditional buffered file systems CQIO Solution: Utilize system memory to store frequently used datafiles in memory Enabled on per-file basis

Database Edition Performance Database Edition with Cached Quick I/O delivers up to 600% better OLTP performance than UFS Tested configuration included: Sun UE (10 CPUs and 6 GB of RAM) Solaris 8 (64-bit) DB Edition 2.2 for Oracle Oracle (64-bit) TPC-C scale factor of 200 warehouses

Oracle9i Oracle Disk Manager ODM API co-developed by Oracle and VERITAS ODM offers simplified management framework for Oracle Database Edition for Oracle is the FIRST enterprise storage solution to support ODM!

Oracle Disk Manager Features Support for File System I/O Raw performance for file systems Single system call for all I/O types Supported on both raw and file system files File Management Contiguous disk space allocation Simplified file creation Supports Oracle Autoextend File Identification Reduced CPU overhead

ODM File IO Oracle without ODM Oracle must resort to many different sets of calls to provide the wide variety of IO types. Example: pwrite()/pread(),async_write(),readv(),read(),write() lio_listio(),kaio() Asynchronous DBWR page flushing requires two calls Oracle with ODM With ODM, Oracle needs only to use a single call odm_io()

Performance with Manageability Oracle Disk Manager Preferred disk management interface (API) defined by Oracle and VERITAS that provides a unified I/O and file management for Oracle9i Eliminates traditional UNIX file system overhead Allows parallel updates to database files for increased throughput Takes advantage of asynchronous I/O Oracle handles locking for data integrity Fewer system calls and context switches Reduced CPU utilization Increased I/O parallelism Efficient file creation and disk allocation Supports Autoextend for file resizing with contiguous

ODM File Identification Feature With ODM, Oracle no longer uses file descriptors. Instead, ODM Identifiers are used. ODM Identifiers are shareable from process to process within the instance Oracle caches ODM Identifiers in the SGA at instance startup ODM Identifier usage reduces Kernel overhead

File Resizing Features ODM supports Oracle’s Autoextend by adding contiguous disk blocks to a tablespace Note: The contiguous extents added to a datafile will not be contiguous with the existing extents This is not adding a datafile, just adding extents Oracle cannot Autoextend a raw partition unless it is a VxVM volume On UFS, the added portion will not be contiguous

ODM versus QIO Functional Comparison ODM is fully automatic upon setup and Oracle9i will utilize ODM for all IO to file system files….except UFS files. VERITAS is currently the only vendor with support for the ODM API Oracle8i has no ODM capability, thus QIO is the solution for Oracle8i QIO and ODM are not the same QIO files are accessed with standard routines for IO QIO files are not created contiguous by Oracle, but by the qiomkfile utility ODM files appear to be just any regular file in the file system QIO files possess a name extension to identify them to the VxFS internals

Database Edition Performance Database Edition 3.0 with ODM delivers Raw I/O performance with file system manageability

Large I/O Optimization VERITAS File System – Extent-based allocation Accelerates I/O by increasing the I/O transfer size in the file system Optimal for large files Large Oracle tablespaces Binary Large Objects (BLOBs) (e.g., images, sounds)

Direct Address 0 / Length Direct Address 1 / Length Direct Address 2 / Length Direct Address 3 / Length Direct Address 4 / Length Direct Address 5 / Length Direct Address 6 / Length Direct Address 7 / Length Direct Address 8 / Length Direct Address 9 / Length Single Indirect Block Double Indirect Block VERITAS File System Inode Extent Addresses Disk Block VERITAS File System: Extent-based Allocation Block-Based Allocation: Spaced allocated 1 block at a time causing fragmentation and hindering performance VxFS Extent-Based Allocation: Groups multiple blocks into large writes Faster than block-at-a-time based operations. Metadata overhead is reduced Less overhead is necessary with sequential reads

VERITAS QuickLog Improves write performance by exporting intent log Transparent to end users Database Edition/HA provides automated QuickLog failover

intent log Data fs1 intent log Data fs2 intent log log volume Data fs1 Data fs2 Standard VERITAS File System Standard VERITAS File System with QuickLog VERITAS File System with QuickLog VERITAS QuickLog Boost File System Write Performance

High Availability

VERTAS Cluster Server Integration of Management, Clustering and Replication Two geographically dispersed sites Linked by public carrier wide area network Site B Site A In the event of a local failure, ORACLE fails over to local machine... Using SAN infrastructure allows you to geographically disperse servers for metropolitan area failover... Integration with data replication allows administrator to direct site level failover in event of catastrophe...    t Host & Array Level Replication Support e.g. t Hardware Based Replication t VERITAS Volume Replicator

Faster Recoverability

Recoverability: Storage Checkpoint A point-in-time image of file system Maintains changed data blocks as database is being updated Mountable: Read-only or R/W All file system functions can be performed

Storage Checkpoint Shares a unique relationship/dependency with the original or primary file system /oradata emp.dbfjune.dbf... Primary File System /oradata emp.dbfjune.dbf... Storage Checkpoint

Storage Checkpoint Applications Storage Rollback On disk recovery Block-level incremental backups Integration with VERITAS NetBackup for Oracle NetBackup for Oracle Advanced BLI Agent Database Clones Allows the database to be queried while loading

Storage Checkpoint Different attributes of Storage Checkpoint Data (Data full) Nodata (Data less) Removable Unmountable

Storage Checkpoint: A Simple Example /oradata A B H G D C E F t No data is copied t Created in seconds t Presents point-in- time image of /oradata by finding data from the primary file system, /oradata Storage Checkpoint When a Storage Checkpoint is first taken:

A Data Storage Checkpoint: As the /oradata changes /oradata A B H G D C E F t Copy-on-write mechanism t Mountable and writable t Copy-on-write in place until the next Storage Checkpoint created or the Checkpoint is removed A’ G’ Storage Checkpoint A G

A Nodata Storage Checkpoint: As the /oradata changes /oradata A B H G D C E F t The changed block is simply marked t These markers are enough to find out the changed data -- A’ and G’ A’ G’ Storage Checkpoint  

VxFS Snapshot vs. Storage Checkpoint Persistency Snapshot is transient Storage used for “before” images Snapshot requires a separate storage pool I/O efficiency and “intelligence” Storage Checkpoints are aware of each other and understand the “chain” relationship Storage Checkpoint API Snapshot allows full backups Storage Checkpoint allows BLIB

How Do I Manage Storage Checkpoints? VxDBA Utility Oracle-aware utility Manages: Storage Checkpoints and Storage Rollback Capacity Planning for Storage Checkpoints Storage Checkpoint scheduling Multiple file systems GUI or command line interface in Database Edition 3.0

VxDBA GUI

VxDBA Storage Checkpoint Scheduler

VxDBA File System Space Alarm VxDBA includes a light weight monitoring agent to: Monitor file system space usage Send alarm notifications and automatically grow file systems and volumes Growth based on user-defined policies Policies can be defined on a per file system basis

VxDBA File System Monitoring Agent

Storage Rollback Storage Checkpoints are simply on-disk backup images Storage Rollback is the “restore” from the on-disk image Copies before-images of data blocks back to the primary file system (block-level restore) “Restores” without going to tapes Storage Rollback is not a database recovery operation DBAs must follow database recovery steps

Storage Rollback Recommendations for Storage Checkpoint and Rollback Frequent on-disk backups to supplement offline backups Protection against logical errors Marker for a batch job Granularity Storage Rollback at the : Database instance level Tablespace level Datafile level

Standard Database Recovery Restore from backup Reapply transactions 00: :00 Back in service 12:00 24:00 15:00 Full DB Backup Transactions Time 0:00

Storage Rollback 10:00 12:00 14:00 24:00 15:00 Restore from last checkpoint Reapply transactions 14: :00 Back in service - fast Full DB Backup Transactions Storage Checkpoints - on-disk, storage efficient backup images Time 0:00

Storage Rollback Simply write back changed (blue) blocks to previous state and then apply redo logs to bring database to desired point in time Managed by VxDBA utility

Storage Rollback Example /oradata A’ B H* G’ D* C’ E F A H G D H’ D’ C First Storage Checkpoint at 1:00AM Second Storage Checkpoint at 12:00PM Suppose Storage Checkpoints were taken at 1am and then at following 12pm

Storage Rollback Example (cont.) /oradata at 1:00AM A B H G D C E F /oradata at 12:00 PM A’ B H’ G’ D’ C E F

Storage Rollback to 12:00PM Before-images on the 12:00PM Storage Checkpoint are copied back to primary file system /oradata A’ B H* G’ D* C’ E F H’ D’ C Second Storage Checkpoint at 12:00PM /oradata at 12:00 PM A’ B H’ G’ D’ C E F H’ D’ C

Storage Rollback to 1:00 AM /oradata A’ B H* G’ D* C’ E F A H G D First Storage Checkpoint at 1:00AM H’ D’ C Second Storage Checkpoint at 12:00PM C A H G D Before-images from 1:00AM and 12:00PM Storage Checkpoints are copied. /oradata at 1:00AM A B H G D C E F

Traditional Backup Approaches Full backups Shrinking backup windows File-level incremental backups Poor fit for database environments Other (block-level) incremental backups SQL-BackTrack Oracle Recovery Manager (RMAN) Our advantage: Storage Checkpoints

Database Edition & NetBackup: Block-Level Incremental Backups Back up only changed data blocks! Higher data availability Virtually eliminates backup windows Enhanced performance Lowers CPU and network resource drain during backups Faster recovery from backups Requires NetBackup Server engine and database server to be a NetBackup client

Block-Level Incremental Backup Changed Blocks Since Last Backup + Block Level Incrementals NetBackup Server NetBackup BLI Backup Extension VERITAS File System with Storage Checkpoints Previous Full Backup Full Restore Minimize Your Database Backup Window

Cold Database Backups with Storage Checkpoints Enables database access and backup in parallel Cold database backup (or offline backup) with minimal downtime A couple of seconds of downtime Shut down database Start the database Storage Checkpoint Resume operation Perform backup Managed by NetBackup

Hot Database Backups with Storage Checkpoints Hot database backup (or online backup) Reduces recovery window with fewer changes to apply A couple of seconds of changes to apply at recovery Begin tablespace backup End tablespace backup Storage Checkpoint Perform backup Managed by NetBackup

Full Backup with Storage Checkpoint /oradata A B H G D C E F Storage Checkpoint at 1:00 AM ABC Bring the database into a consistent state Take a Storage Checkpoint Resume database operation Back up from the Storage Checkpoint The Storage Checkpoint presents a “frozen” image of the file system

During Full Backup /oradata A B H G D C E F During backup, the database is accessible and being updated The Storage Checkpoint continues to present a “frozen” image of the file system HGD ABC EF A’ G’ Storage Checkpoint at 1:00 AM G A

After Full Backup /oradata A B H G D C E F Storage Checkpoint at 1:00 AM H’ D’ After the full backup, the database continues to be updated So… Which blocks have changed since the full backup? What are the changes? A’ H’G’D’ A’ G’ A G H D

Block-Level Incremental Backup /oradata A’ B H’ G’ D’ C E F Before-images saved on the first Storage Checkpoint indicate which blocks have changed since the full backup Changed data is read from /oradata A’ D’ A H G D First Storage Checkpoint at 1:00 AM Second Storage Checkpoint at 12:00 PM

During Block-Level Incremental Backup /oradata A’ B H’ G’ D’ C E F A H G D First Storage Checkpoint at 1:00 AM Second Storage Checkpoint at 12:00 PM H* D* D’ H’ During backup, the database is being updated Changes after 12:00 PM are saved on the second Storage Checkpoint The second Storage Checkpoint presents a “frozen” image of /oradata at 12:00 PM Changed data is read from the second Storage Checkpoint or /oradata A’ D’ G’H’ C’ C

Restore from BLI Backup Benefit: BLI Backup enables more frequent backups More up-to-date backup images Less logs to apply upon restore Faster database recovery + Block Level Incrementals Previous Full Backup Full Restore

Creating a Clone Database Using mounted Storage Checkpoints, a clone database can be created Uses: Oracle queries while database is being loaded Recovery from “logical errors” – dropped tablespace or datafile Reporting or data mining using a point-in-time image of production data

Example: Recover a Dropped Table Without Downtime Using Storage Checkpoints

Steps to Recover Table 1. Create the Storage Checkpoint 2. Mount the Storage Checkpoint 3. Create clone database using the mounted Storage Checkpoint 4. Export the table from the clone database 5. Import the table back into to the original database

vxckpt_create –S ORACLE_SID -H ORACLE_HOME –o online vxckpt_mount –S ORACLE_SID –c CHECKPOINT_NAME -m MOUNT_POINT –o rw dbed_orarel CLONE_DATABASE MOUNTABLE_CHECKPOINT exp userid/passwd imp userid/passwd Note: For more parameters refer to “Oracle Utilities” documentation.

Database Edition for Oracle Summary

Benefits Summary Increase performance Increase manageability and efficiency Increase availability of Oracle data The Optimal Foundation for Oracle: “ We believe that those installing new databases should seriously consider using VERITAS Database Edition for Oracle for the combination of performance and manageability it provides. ” Oracle Large Systems Support Group