Database Edition for Oracle Storage Management & High Performance for Oracle Database Servers erling.kvalheim@veritas.com

Market Drivers Faster access to data Are you using file systems or raw disk partitions to Oracle data? Continuous availability (24x7) of mission-critical Oracle databases How much does downtime cost your business in regard to lost user productivity, reduced company revenue, poor customer service? Easier management of increasing data Do your DBAs have to learn how to manage raw disk partitions to gain database performance?

What are the Database Editions? Integrated storage management solutions optimized for specific application areas Database Edition for Oracle Database Edition for Sybase The Editions development team are like a super-experienced VERITAS INTEGRATORs developing solutions with the VERITAS point products. In addition to integrating the VERITAS point products into application specific solutions, the Editions Engineering team have a big advantage over other possible integrators because they know the products very well and have access to the base products engineering resources. Because we know the products so well, we can add functionality and exploit the interaction between the point products. We also work closely with VERITAS Enterprise application partners such as Oracle, Sybase and SAP to ensure that these are vendor-endorsed solutions The Editions are: system integration and performance tested together tested extensive on the application-specific environment that they support they carry vendor-endorsements from Oracle and Sybase easy-to-use installation process Current Editions offerings are: READ SLIDE We are also planning several new Editions for 2H 1999!

Software Stack QuickLog HA Agent Oracle Database HA Agent Edition Oracle Database HA Agent VERITAS Cluster Server VxDBA Administration Utility QuickLog for File System Standard Edition (Cached) Quick I/O for Databases File System with Storage Checkpoints Volume Manager

Feature Overview Quick I/O & Cached quick I/O Raw device performance with file system manageability Cached Quick I/O for up to 150% performance improvement over raw devices VERITAS Volume Manager & VERITAS File System Online disk & file management Stripped / Mirrored arrays Java-based Storage Administrator GUI

Feature Overview (cont’d) Storage Checkpoints Block-Level Incremental Backup (w/ NetBackup) Storage Rollback for immediate “point-in-time” recovery from “logical errors” QuickLog for File System Automatic monitoring and recovery of Oracle (HA Edition) Vendor Certification – Oracle OSCP

Database Edition for Oracle Enhanced Performance Quick I/O & Cached Quick I/O

Database Edition for Oracle Performance Increased performance increased productivity Equal to raw device performance using Quick I/O Greater than raw performance using Cached Quick I/O for read intensive workloads Large I/O optimization Accelerated I/O performance for large files (e.g., video, images)

Database Performance Issues with Conventional File Systems Redundant data buffering System buffer cache Database buffer cache Redundant buffer copying Inefficient use of memory Single writer lock per file at UNIX file system level UNIX file-level lock RDBMS row- or page-level lock Serialized write operations Impact on performance in multi-user client/server environments Kernelized asynchronous I/O (KAIO) Supported only on raw devices, not on regular files

Building Oracle Databases on Raw Disks vs. File Systems Unique, total storage foundation solution to deliver the best of both worlds Database Edition for Oracle Raw Disks Conventional File Systems Advantages Disadvantages Advantages Disadvantages Manageability Tablespace organization System-wide backup and restore policies Easy to create and expand files for Oracle Performance Best OLTP performance Data Reliability No potential for data loss with data written to disks directly Manageability “Invisible” locations for tablespaces Difficult to grow Performance Lower database throughput (30-90% of raw disk) Higher CPU overhead Data Reliability Potential data loss

Quick I/O Breakthrough VERITAS File System interface technology Presents regular VERITAS File System files to Oracle as raw character devices Allows parallel updates to database files for increased throughput Takes advantage of kernel async I/O (Solaris’ KAIO) Oracle handles locking for data integrity Simple scripts convert existing files to Quick I/O and create new database files as Quick I/O files Eliminates traditional UNIX file system overhead Quick I/O regular file raw device RDBMS Server

VERITAS Cached Quick I/O Why Cached Quick I/O? 4 GB maximum limit on Oracle buffer cache size for systems (32-bit) Very large, enterprise class machines with several GB of memory (e.g., 64 GB on Sun E10000) Current solution: Traditional buffered file systems Goal: Retain Quick I/O reliability advantages over traditional buffered I/O systems, yet improve performance Cached Quick I/O can be turned on on a per file basis. The DBA’s guide outlines a procedure for determining which files experience the greatest gain by having Cached Quick I/O enabled. For example, due to its read-ahead algorithm, a customer may want to turn on Cached Quick I/O when running the monthly accounting reports. Cached Quick I/O will allow users to take advantage of full system memory without having to change to 64-bit operating systems.

Cached Quick I/O Overview Implemented as a buffered read, direct write solution Retains data reliability advantage of direct write Gains read-ahead at the File System and memory-to-memory copy performance advantage Easy online management to turn Cache on/off for Quick I/O files Like Quick I/O, enabled on a per-file basis Multiple database instances can co-exist with selective caching for specific datafiles Little change to existing configuration Does not require changes to OS or database version levels (to 64-bit architecture)

Cached Quick I/O Outperforms UFS on 64-bit Solaris 7 Database Edition 2.2 with Cached Quick I/O delivers up to Six times the performance of UFS using Direct I/O The figure shows how OLTP performance was affected by the percentage of system memory used by Oracle buffers. As expected, increasing the Oracle buffer size improved the OLTP throughput for both the Quick I/O and raw I/O configuration. Cached Quick I/O still helped when some of the database blocks can be cached in the operating system. However, when the Oracle SGA size became closer to the total memory size, data caching in the operating system may actually slow down the OLTP performance. Another observation from the plots is that the best OLTP performance may be achieved by Cached Quick I/O, if the ratio between Oracle SGA and the operating system cache can be properly tuned. Tested configuration included: Sun E 10000 (10 CPUs and 6 GB of RAM) Solaris 7 (64-bit) DB Edition 2.2 for Oracle Oracle 8.1.5 (64-bit) TPC-C scale factor of 200 warehouses

Large I/O Optimization VERITAS File System allocates disk space in groups of contiguous blocks or “extents” Extent-based allocation can accelerate 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)

VERITAS QuickLog Improves VERITAS File System Write performance by exporting intent log Updates intent log in parallel with accessing file data Eliminates the seek time between intent log area and file system data area Transparent to end users Minimal system administration setup Database Edition/HA provides automated QuickLog failover

VERITAS QuickLog Boost File System Write Performance Standard VERITAS File System with QuickLog intent log log volume Data fs1 fs2 fs1 fs2 intent log intent log Data Data The standard VERITAS file system intent log resides on the same disk with the data. With the accelerator for NFS a separate volume is set up so that the intent log resides on a separate disk. This means that data writes and log writes can happen in parallel and less time is spent by the disk head moving to a different location to write to the log and the data itself.

Database Edition for Oracle Faster Recoverability Storage Checkpoint

Storage Checkpoint A point-in-time image of file system Disk and I/O efficient Not an extra “mirror” Use copy-on-write semantics to maintain changed blocks Instantaneous on-disk backup image Persistent across reboots Multiple Storage Checkpoints can be taken Before images are saved only once to the latest Storage Checkpoint Maintains changed data blocks as database is being updated No post-processing needed for scanning for changed data blocks Mountable All file system functions can be performed

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

Storage Checkpoint Applications Storage Rollback On disk recovery from logical errors such as table deletions and database corruption Block-level incremental backups NetBackup Advanced BLI Agent for Oracle RMAN Proxy Copy “Script-based” BLI Backup Database Replication Option Off host processing

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

A Data Storage Checkpoint: As the /oradata changes B H G D C E F Storage Checkpoint Copy-on-write mechanism first copies the before-image to the Storage Checkpoint and then updates the data block in the primary file system Mountable and writable Copy-on-write in place until the next Storage Checkpoint created or the Checkpoint is removed A’ A G’ G

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

How Do I Manage Storage Checkpoints? VxDBA, an Oracle-aware menu-driven utility to manage Storage Checkpoints and Storage Rollback Database may be configured using multiple file systems Taking Storage Checkpoints of multiple file systems must be coordinated to ensure database consistency If database offline, Storage Checkpoint is equivalent to cold backup image If database online, VxDBA switches database into backup mode, creates Storage Checkpoints, and takes database out of backup mode Storage Checkpoint is now a hot backup image Command line interface in Database Edition

Storage Rollback A direct application of Storage Checkpoint technology Storage Checkpoints are simply on-disk backup images Consistent, stable images of a file system at a particular point in time Storage Rollback is “restore” from the on-disk backup or Storage Checkpoints 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 e.g., weekly full backups, nightly incrementals, and Storage Checkpoints during the day Protection against logical errors e.g., accidentally dropped tablespaces Marker for a batch job e.g., use Storage Checkpoint and Storage Rollback to “undo” batch jobs if they cause data corruption Granularity Storage Checkpoints are created for an Oracle instance based on VxFS file systems Storage Rollback is implemented to roll back on a per database instance, tablespaces (a set of files), and a specific file (datafile) basis

Rollback from Storage Checkpoints Managed by VxDBA utility Storage Rollback Rollback from Storage Checkpoints = 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 12 pm

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 H’ D’ C Second Storage Checkpoint at 12:00PM A’ B H* G’ D* C’ E F /oradata at 12:00 PM A’ B H’ G’ D’ C E F /oradata Before-images on the 12:00PM Storage Checkpoint are copied back to the primary file system, /oradata C D’ H’

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

Traditional Backup Approaches Full backups Shrinking backup windows Approaches to minimize downtime Hot database backups Third mirror break-off Rolling backups (full + tables) File-level incremental backups Poor fit for database environments Other (block-level) incremental backups SQL-BackTrack Oracle8.x’s Recovery Manager (RMAN) Our advantage: Storage Checkpoints

Database Edition w/ NetBackup: Block-Level Incremental Backups Back up only changed data blocks! Higher data availability Virtually eliminates backup windows Allows more frequent backup schedules Backups contain up-to-date data Enhanced performance Significantly lowers CPU and network resource drain during backups Faster recovery from backups (less redo logs to apply) Requires NetBackup Server engine and database server to be a NetBackup client BLIB backs up only the changed data blocks. For example, if you have a several gigabyte database file, but only a few table entries have changed, do you really want to back up the whole file? Of course not! BLIB allows you to backup only the data that has changed at the block level, with a block being as small as 1K. Due to vast reduction in data backed up, backup windows are shortened, so backups can be taken more often. This makes restore faster since the backup images are more up-to-date. Similarly performance is enhanced due to the greatly shortened backup window and accordingly recovery to a consistent database state is much faster than having to apply all the Oracle redo logs.

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

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

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

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

Storage Checkpoint at 1:00 AM During Full Backup Storage Checkpoint at 1:00 AM /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 A’ A G’ G A B C D E F G H

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

Block-Level Incremental Backup Second Storage Checkpoint at 12:00 PM A H G D First Storage Checkpoint at 1:00 AM Bring the database into a consistent state /oradata A’ B H’ G’ D’ C E F Take a second Storage Chkpt Resume database operation Back up using the Storage Checkpoints 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’

During Block-Level Incremental Backup Second Storage Checkpoint at 12:00 PM A H G D First Storage Checkpoint at 1:00 AM 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 /oradata A’ B H’ G’ D’ C E F C’ C D* D’ A’ D’ H* H’ G’ H’

Restore from BLI Backup Restoring incremental image requires restoring full backup plus all incrementals to get to desired point in time. 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

Database Edition for Oracle Improved Manageability

Manageability VxDBA utility to manage Storage Checkpoints and Storage Rollback as well as plan for capacity usage Familiar file system administration for Oracle database files Combines raw I/O performance and ease of file system management Large database configuration support Guide to simplify administration of database storage Java-based interface to manage storage configuration from central console

VxDBA Overview VxDBA allows DBAs to Manage their databases Display information on performance and configuration Plan for additional storage needed by Storage Checkpoints Manage Storage Checkpoint and Storage Rollback operations Configure light weight monitoring agent to manage file system space for Storage Checkpoints

VxDBA Main Menu VERITAS Database Edition for Oracle (ORACLE_SID 'PROD') Menu: Database Main 1 Database Administration 2 Display Database/VxDBA Information 3 Storage Checkpoint Administration 4 Storage Rollback Administration 5 Monitoring Agent Administration 6 Storage Checkpoint Capacity Planning 7 Database Replication Option ? Display Help About the Current Menu q Exit From Current Menu x Exit From VxDBA Utility Select Operation to Perform:

Ease of File System Management Administrative comforts Familiar namespace and utilities to manage Oracle database files Datafiles can be grouped together for storage hierarchy Common backup strategies for database and non-database files

Large Database Configuration Support Database Edition can support file systems up to 1 TB in size File system sizes are not limited to underlying device sizes No longer need to manage multiple file systems per database Online resizing further simplifies file system management

Database Administrator’s Guide Cookbook for setting up and tuning database environments Tailored for DBAs to optimize database storage layouts Presents various storage configuration options Recommends optimal configurations specific to database application workloads

VERITAS Storage Administrator Visual configuration management and performance analysis Allows one-step graphical execution of common configuration management steps

Product Description Hosts Supported System Requirements Solaris 2.6, 7, and 8 System Requirements Oracle 7.3 to 8i Software Components VERITAS Volume Manager 3.1 VERITAS File System 3.4 with Quick I/O Database Edition/HA (VCS) for Oracle VERITAS Cluster Server 1.2.1 and VCS Agent for Oracle Intelligent installation script requires only single key DB Edition runs on Solaris today and work is underway to release an identical version for HP. We currently have similar functionally on HP packaged as the Storage Edition without the Volume Manager component. DB Edition 2.1 for Oracle works with Oracle 7.3 or later. If the customer is currently using OPS, it is probably best to walk away from trying to sell them DB Edition. DB Edition does not work with OPS (a cluster product). CFS and CVM would be required and they are not available until 2000/2001. OPS requires specific HW configurations and is difficult to manage. So, if the customer is considering OPS we can sell DB Edition against it. It also does not scale well, so VCS could be sold against it as long as immediate access is not required.

Database Edition for Oracle High Availability

The Need for High Availability Many factors contribute to potential downtime Software Hardware People Planned downtime (for maintenance tasks) Downtime impacts business operations Revenue, customer service, and productivity at risk

Annual Internet Shopping Cost $50+ million $20+ million $10 million $988,750 $98,000 $9,417 $950 Annual Brokerage System Cost $3+ billion $1+ billion $560 million $280 million $56 million $5,590,000 $537,500 $53,750 % uptime 450+ hours 180+ hours 87.6 hours 43.7 hours 8.75 hours 52 minutes 5 minutes 30 seconds Annual downtime A V A I L A B I L I T Y 99.9999 99.999 99.99 99.9 99.5 99.0 98.0 95.0 Savings ($)

Database Edition for Oracle Availability Online Administration Storage reconfiguration and maintenance without downtime File System Monitoring Automated, proactive monitoring of file system to avoid unexpected “out-of-space” conditions Database Edition/HA Automatically monitor Oracle processes and restart Oracle instance on another server in case of failure

Online Administration Enables DBAs and system administrators to meet changing database storage requirements without database downtime Supports online tablespace growth Online resizing of file systems Allows database storage reconfiguration Defragmenting mounted file systems

Online Administration Example Traditional w/VxVM and VxFS Locate new disk space Create a new file system Stop work Copy files to the file system Resume work Select “resize a file system” from a menu Enter the new file system size No interruption to users or applications Extend a file system

Intelligent File System Control Policy-driven File Management Why ? Lack of file system free space can cause widespread application failure How ? Included Agent monitors average available free space of VERITAS File System If average free space falls below threshold set by the administrator, the agent will automatically grow the File System and underlying volume if need be to enforce free space policy Configured using VxDBA utility REACTIVE PROACTIVE

VxDBA File System Space Alarm Display the space usage of file systems and Storage Checkpoints, to display current space alarm settings, and enable and configure space alarm settings Display File System Space Usage Display File System Space Alarm Settings Enable/Disable/Modify Space Alarm Settings 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

Database Edition/HA VERITAS Cluster Server Sophisticated availability configuration management Clustered HA solution allowing 2-32 server scalability 1:1, Any:1 and 1:Any policy-based failover Application level cascading failover Fast Kernel-to-Kernel communication & failover Certified 3rd party support for SCSI, SAN & NAS storage Centralized Cluster Manager console for HP-UX, Solaris and Windows NT VERITAS Cluster Server for NT is the culmination of over 7 years of HA experience, and provides the most mature HA feature set available on the NT platform. Clustered HA Solution: Allows seamless scalability from two to thirty-two servers in an active/active configuration meaning the cost of implementing HA becomes cheaper the more servers are added into the cluster. 1:1, Any:1 and 1:Any policy-based failover: VCS offers a variety of configurations from the traditional HA (1:1) active/active failover, multiple servers failing over to a dedicated standby server (N:1) and cascading failover from one machine, to another, to another in the event of multiple server failure (1:N). Fast Kernel-to-Kernel communication & failover: VCS has components like GAB/LLT which are embedded into the operating system, which means that communication between nodes for atomic cluster configuration and monitoring, as well as fast failover. Certified 3rd party support for SCSI, SAN and NAS storage: Through the VERITAS iLab, we are able to offer qualified support for many third party devices. Integrates with the Volume Manager & File System: Unique integration with the VERTIAS Foundation technologies, means that majority of causes of planned and unplanned downtime can be eliminated. VCS/Foundation integration features offered such as Import/Deport aids quick and clean failover, journalling understood, to enable fast recovery in the event of failure. Centralized Cluster Manager console….: Common management console across operating systems aiding skills transfer.

Benefits Summary Increase performance up to 600% over UFS with file system manageability Quick I/O & Cached Quick I/O Reduce production database downtime Online volume and file system administration with VxVM and VxFS Minimize database backup window Block-Level Incremental Backup Recover quickly from logical errors Storage Checkpoints and Storage Rollback Quick restore of Oracle databases after application or system failure Automatic failover capability - HA Edition with VCS

Business Without Interruption