14 Copyright © 2005, Oracle. All rights reserved. System Management Tasks and Techniques

14-2 Copyright © 2005, Oracle. All rights reserved. Objectives After completing this lesson, you should be able to do the following: Demonstrate table and partition compression techniques Implement resumable sessions in your data warehouse Implement an effective backup and restore strategy for your data warehouse Plan a security strategy for a data warehouse

14-3 Copyright © 2005, Oracle. All rights reserved. Are There Execution Problems? Use V$PQ_TQSTAT to find out if there is data distribution skew or bad object statistics: –Contains traffic statistics between slaves at table queue level –Valid only when queried from the parallel session Check I/O and CPU bound at the operating system level and decide on the parallelism Use the Automatic Workload Repository to examine useful statistics

14-4 Copyright © 2005, Oracle. All rights reserved. Performance Monitoring and Tuning Statistics gathering and monitoring activities are mainly automatic. Administer and display the output of the gathering and tuning tools with Enterprise Manager: –Automatic Workload Repository –Automatic Database Diagnostic Monitor –SQL Access Advisor –End to End Application Tracing

14-5 Copyright © 2005, Oracle. All rights reserved. Statistics Collection The STATISTICS_LEVEL initialization parameter controls major statistics collection in the database. STATISTICS_LEVEL can have one of three values: –When set to BASIC, no advisories or statistics are collected. – TYPICAL is the default value and ensures collection for all major statistics. – ALL includes all items collected with TYPICAL plus operating system and row source execution data.

14-6 Copyright © 2005, Oracle. All rights reserved. End to End Application Tracing End to End Application Tracing: Simplifies the process of diagnosing performance problems in multitier environments Helps to identify the source of an excessive workload Uses a client identifier to uniquely trace a specific end client through all tiers Allows you to identify what a users session is doing at the database level

14-7 Copyright © 2005, Oracle. All rights reserved. End to End Application Tracing Using EM EM Database Control interface:

14-8 Copyright © 2005, Oracle. All rights reserved. Compression Table compression is optimized for relational data. There is virtually no negative impact on the performance of queries against compressed data. There can be a significant positive impact on queries accessing large amounts of data. The data is compressed by eliminating duplicate values in a database block. All database features and functions that work on regular blocks also work on compressed blocks.

14-9 Copyright © 2005, Oracle. All rights reserved.

14-10 Copyright © 2005, Oracle. All rights reserved. What Can Be Compressed? Objects that can be compressed include: –Tables –Partitions –Materialized views –B-tree indexes Compression works for all data types except: –Variants of large objects (LOBs) –Data types derived from LOBs, such as VARRAY s stored out of line or XML data type stored in a character large object (CLOB) Tables that are frequently updated should not be compressed.

14-11 Copyright © 2005, Oracle. All rights reserved.

14-12 Copyright © 2005, Oracle. All rights reserved. Compression: Examples Simple compressed partitioned table: Partitioned table with one compressed partition: CREATE TABLE sales_range salesman_id NUMBER(5),salesman_nameVARCHAR2(30), sales_amount NUMBER(10),sales_date DATE) COMPRESS PARTITION BY RANGE(sales_date)... CREATE TABLE sales_list (salesman_id NUMBER(5),salesman_name VARCHAR2(30), sales_state VARCHAR2(20),sales_amount NUMBER(10)) PARTITION BY LIST(sales_state) (PARTITION sales_west VALUES('California', 'Hawaii') COMPRESS, PARTITION sales_east VALUES('New York', 'Virginia', 'Florida'),...

14-13 Copyright © 2005, Oracle. All rights reserved. Maximizing Compression Ratios Load data ordered (sorted) to maximize the duplication of values within a database block. If external tables are used for loading, add an ORDER BY clause to the SELECT statement. Use larger block sizes.

14-14 Copyright © 2005, Oracle. All rights reserved. Resumable Sessions Resumable statements enable large database operations to be suspended and resumed. Space-limit errors can be corrected, allowing the hung session to resume. Issue ALTER SESSION ENABLE RESUMABLE before initiating a long-running operation: – TIMEOUT specifies the time window for intervention. – NAME specifies the name of the resumable session. ALTER SESSION ENABLE RESUMABLE TIMEOUT 600 NAME 'resumable_session_name';

14-15 Copyright © 2005, Oracle. All rights reserved. Data Warehouse Backup and Recovery Why should a data warehouse backup and recovery strategy not be just like that of an OLTP database? A data warehouse is typically much larger than an operational system. A data warehouse often has lower availability requirements than an OLTP system. Data warehouse updates are often reproducible from sources other than database logs. Data warehouses contain historical data and often, large portions of the older data are static.

14-16 Copyright © 2005, Oracle. All rights reserved.

14-17 Copyright © 2005, Oracle. All rights reserved. Recovery Time Objective (RTO) An RTO is the number of hours in which you want to be able to recover your data. To formulate an RTO: Understand your recovery readiness, risk areas, and the business costs of unavailable data. Transform the recovery requirements into backup and recovery strategies. Deploy and integrate the solution into your environment to back up and recover your data. Test your recovery plans at regular intervals. –Refine it as your data, IT infrastructure, and business processes change.

14-18 Copyright © 2005, Oracle. All rights reserved. Recovery Point Objective (RPO) Automated recovery procedures Manual recovery procedures No backup of data Restore backup Data reinserted via ETL RPO Backups run at scheduled intervals. RTO # 1 Critical data is available, database is open. RTO # 2 Remainder of data is inserted. 0 -nn hours +nn hours +nnn hours Normal operations

14-19 Copyright © 2005, Oracle. All rights reserved. More Backup and Recovery Considerations Hardware is the limiting factor to fast backup and recovery. –More data means a longer backup window. RMAN can fully utilize, in parallel, all available tape devices. Consider breaking the database backup over a number of days. RMAN backs up all database files that have not been backed up in the last 24 hours. The backup job is limited to 4 hours. RMAN> BACKUP DATABASE NOT BACKED UP SINCE \ 'sysdate – 1' PARTIAL DURATION 4:00 MINIMIZE TIME;

14-20 Copyright © 2005, Oracle. All rights reserved.

14-21 Copyright © 2005, Oracle. All rights reserved. Backup and Recovery Tools Recovery Manager reduces the administration work associated with your backup strategy. Enterprise Manager enables backup and recovery to be done by a point-and-click method. Data Pump provides high-speed, parallel, bulk and metadata movement of database contents. User-managed backups are done using operating system–specific utilities.

14-22 Copyright © 2005, Oracle. All rights reserved.

14-23 Copyright © 2005, Oracle. All rights reserved. Backup and Recovery: Best Practices Use ARCHIVELOG mode. Use RMAN. Leverage read-only tablespaces. Plan for nologging operations in your backup and recovery strategy. Not all tablespaces in a data warehouse are equally significant from a backup and recovery perspective.

14-24 Copyright © 2005, Oracle. All rights reserved.

14-25 Copyright © 2005, Oracle. All rights reserved. NOLOGGING Backup and Recovery Strategies Extract, transform, load (ETL): Uses several Oracle tools and a combination of methods to reload data –Transportable tablespaces, SQL*Loader, Data Pump, external tables Incremental backups: Are a more automated backup and recovery strategy in the presence of nologging operations Provide the capability to back up only the changed blocks since the previous backup Are faster when using the block change tracking feature

14-26 Copyright © 2005, Oracle. All rights reserved. Employing Incremental Backups Incremental backups of data files capture data changes on a block-by-block basis. Speed up backups by using block change tracking –The database tracks the physical location of all database changes. –RMAN automatically uses the change tracking file to determine which blocks need to be read. –Sizing the block change tracking file: Best practice: Use block change tracking and make an incremental backup after nologging direct load operations. ((threads * 2) + number_of_old_backups) * (database_size_in_bytes)

14-27 Copyright © 2005, Oracle. All rights reserved.

14-28 Copyright © 2005, Oracle. All rights reserved. Data Warehouse Security The consolidated model provides several benefits for data warehouse security: Consistent security model Central, expert management Fewer points of attack Simpler security maintenance

14-29 Copyright © 2005, Oracle. All rights reserved.

14-30 Copyright © 2005, Oracle. All rights reserved. Layered Security Model Provide multiple security layers so that failure of a single layer does not compromise critical data. The security layers available in Oracle Database 10g include: –Role-based access control –Row-level security employing Virtual Private Database and Oracle Label Security –Auditing the database –Encryption

14-31 Copyright © 2005, Oracle. All rights reserved.

14-32 Copyright © 2005, Oracle. All rights reserved. Transparent Data Encryption Transparent Data Encryption (TDE) is a component of Oracle Advanced Security. TDE allows you to encrypt selected column data without having to manage the encryption key. Encrypt sensitive data such as credit card numbers before it is stored in the database. Oracle Advanced Security protects data by using industry-standard encryption methods: –AES –Triple DES

14-33 Copyright © 2005, Oracle. All rights reserved. Implementing TDE 1.As SYSDBA, create the encrypted wallet file and set the initial password: 2.Create the table: 3.Verify encryption: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "secret_passwd"; create table SH.CUST_SS_INFO(first_name varchar2(11), last_name varchar2(10),ss_num varchar2(20) ENCRYPT NO SALT); SQL> select * from DBA_ENCRYPTED_COLUMNS; OWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL SH CUST_SS_INFO ss_num AES 192 bits key NO

14-34 Copyright © 2005, Oracle. All rights reserved.

14-35 Copyright © 2005, Oracle. All rights reserved. Summary In this lesson, you should have learned how to: Demonstrate table and partition compression techniques Implement resumable sessions in your data warehouse Implement an effective backup and restore strategy for your data warehouse Plan a security strategy for a data warehouse

14-36 Copyright © 2005, Oracle. All rights reserved. Practice 14: Overview This practice covers the following topics: Implementing table compression and investigating the resultant compression ratios Using resumable sessions Implementing Transparent Data Encryption