DB2 recovery expert for multiplatforms

DB2 recovery expert for multiplatforms

DB2 Recovery Expert is one of the most recent IBM Data Management Tools for Multiplatforms. It provides an easy-to-use environment that even less experienced DBAs can successfully use, to complete highly sophisticated and efficient recovery techniques in minimal time. Built-in SMART (Self-Managing a...

Descripción completa

Detalles Bibliográficos
Autor principal: Steegmans, Bart (-)
Autor Corporativo: International Business Machines Corporation. International Technical Support Organization (-)
Otros Autores: Samson, Mark, Shah, Manish
Formato: Libro electrónico
Idioma:Inglés
Publicado: [San Jose, Calif. : IBM Corp., International Technical Support Organization 2002.
Edición:1st ed
Colección:IBM redbooks.
Materias:
IBM Database 2.
Database management.
Data recovery (Computer science)
Ver en Biblioteca Universitat Ramon Llull:https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009627557906719
Tabla de Contenidos:
  • Front cover
  • Summary of changes
  • November 2002, First Edition
  • Contents
  • Figures
  • Tables
  • Examples
  • Notices
  • Trademarks
  • Preface
  • The team that wrote this redbook
  • Become a published author
  • Comments welcome
  • Chapter 1. Introduction to DB2 Tools for Multiplatforms
  • 1.1 The DB2 Tools for Multiplatforms
  • 1.1.1 Database administration tools
  • 1.1.2 Performance management tools
  • 1.1.3 Recovery and replication tools
  • 1.1.4 Application management tools
  • 1.2 DB2 Web Query Tool
  • 1.3 DB2 Table Editor
  • 1.4 DB2 Recovery Expert
  • 1.5 DB2 High Performance Unload
  • 1.6 DB2 Performance Expert
  • 1.7 DM Tools for Multiplatforms ordering information
  • Chapter 2. Introduction to DB2 Recovery Expert
  • 2.1 Overview
  • 2.2 Key features
  • 2.2.1 Simple, easy to use interface
  • 2.2.2 Dropped object restore
  • 2.2.3 Greater granularity in recovery operations
  • 2.2.4 Point-in-time recovery of objects
  • 2.2.5 Enhanced recovery performance
  • 2.2.6 SQL report generation
  • 2.2.7 Selective SQL undo/redo
  • 2.3 Key concepts
  • 2.3.1 Versioning Repository
  • 2.3.2 Minilogs
  • 2.3.3 Log analysis
  • 2.3.4 Object translation
  • 2.3.5 Our environment
  • Chapter 3. Installation and configuration
  • 3.1 Installation requirements
  • 3.1.1 Hardware requirements
  • 3.1.2 Software requirements
  • 3.2 Installation instructions
  • 3.2.1 Starting InstallShield
  • 3.2.2 The InstallShield process
  • 3.3 Post-installation configuration
  • 3.3.1 Environment variables
  • 3.4 Getting started
  • 3.4.1 Launching DB2 Recovery Expert
  • 3.4.2 Connecting to a database
  • 3.5 DB2 configuration changes
  • 3.5.1 LOGRETAIN
  • 3.5.2 Performance
  • 3.5.3 USEREXIT (optional)
  • 3.5.4 DROPPED TABLE RECOVERY (optional)
  • 3.6 DB2 Recovery Expert tasks
  • 3.6.1 Create Versioning Repository
  • 3.6.2 Create minilogs
  • 3.7 Troubleshooting.
  • 3.7.1 Tracing the install process
  • 3.7.2 The DB2 Recovery Expert log file
  • 3.7.3 Changing the amount of information logged
  • 3.7.4 Common problems
  • Chapter 4. Managing recovery assets
  • 4.1 Backups
  • 4.1.1 The importance of backups
  • 4.1.2 Backup types
  • 4.1.3 Storage managers
  • 4.1.4 Scheduling backups
  • 4.2 Versioning Repository
  • 4.2.1 The importance of the Versioning Repository
  • 4.2.2 How to create and update the Versioning Repository
  • 4.2.3 When to update the Versioning Repository
  • 4.2.4 Backing up the Versioning Repository
  • 4.3 Minilogs
  • 4.3.1 The importance of minilogs
  • 4.3.2 How to create and update minilogs
  • 4.3.3 For which objects should I create minilogs?
  • 4.3.4 How often to update minilogs
  • 4.3.5 When are minilogs used?
  • 4.4 DB2 Recovery Expert metadata
  • Chapter 5. Log analysis
  • 5.1 Introduction to log analysis
  • 5.1.1 What is log analysis?
  • 5.1.2 Prerequisites for log analysis
  • 5.1.3 Accessing log analysis
  • 5.2 Scenario A: Recovery using log analysis
  • 5.2.1 Scenario description
  • 5.2.2 Prerequisites for the scenario
  • 5.2.3 Scenario time line
  • 5.2.4 Recovery options without DB2 Recovery Expert
  • 5.3 The DB2 log analysis tool
  • 5.3.1 Getting started with the DB2 log analysis tool
  • 5.3.2 Analyzing changes to a single table
  • 5.3.3 Analyzing changes to all tables
  • 5.3.4 Problem resolved
  • 5.4 The command line interface: db2la
  • 5.4.1 Analyzing changes to the EMPLOYEE table
  • 5.4.2 Analyzing changes to all tables
  • 5.5 Considerations
  • 5.5.1 Recovery Expert quiesces the table space
  • 5.5.2 Recovery Expert works one row at a time
  • 5.5.3 Redo SQL will not necessarily be the same as the original SQL
  • 5.5.4 Masked update reconstruction
  • 5.5.5 It only shows committed transactions
  • 5.5.6 DATA CAPTURE CHANGES
  • 5.5.7 Referential Integrity
  • 5.5.8 GENERATED ALWAYS columns.
  • 5.5.9 Triggers
  • 5.6 FAQ
  • 5.6.1 Which interface should I use?
  • 5.6.2 Can you find all changes made by one application?
  • 5.6.3 Can you find all changes made by one user (authid)?
  • 5.6.4 Does log analysis work with LOB data?
  • 5.6.5 What if the table has changed?
  • 5.6.6 What if other SQL is run while Undo/Redo SQL is running?
  • Chapter 6. Point-in-time recovery
  • 6.1 Scenario B: PIT recovery if SQL has been run
  • 6.1.1 Scenario description
  • 6.1.2 Prerequisites for the scenario
  • 6.1.3 Scenario time line
  • 6.1.4 Recovery without DB2 Recovery Expert
  • 6.2 PIT recovery of a table
  • 6.3 PIT recovery of a table space
  • 6.3.1 UNDO SQL using the DB2 logs
  • 6.3.2 Restore from a backup image and roll forward
  • 6.4 PIT recovery of a database
  • 6.4.1 UNDO SQL using the DB2 logs
  • 6.4.2 Restore from a backup image and roll forward
  • 6.5 Scenario C: PIT recovery if DDL has been run
  • 6.5.1 Scenario description
  • 6.5.2 Prerequisites for the scenario
  • 6.5.3 Scenario time line
  • 6.5.4 Recovery options without DB2 Recovery Expert
  • 6.6 Recovery from Scenario C
  • 6.7 PIT recovery of DEPARTMENT table
  • 6.8 PIT recovery of ORG table
  • 6.9 PIT recovery of a table space
  • 6.10 PIT recovery of database
  • 6.11 Scenario D: PIT recovery with Referential Integrity
  • 6.11.1 Scenario description
  • 6.11.2 Prerequisites for the scenario
  • 6.11.3 Scenario time line
  • 6.11.4 Recovery without DB2 Recovery Expert
  • 6.12 Recovery from Scenario D
  • 6.12.1 Recovery using the DB2 RE GUI
  • 6.12.2 Recovery using db2la
  • 6.12.3 Further discussion of the effects of Referential Integrity
  • 6.13 Scenario E: PIT recovery using command line
  • 6.13.1 Scenario description
  • 6.13.2 Prerequisites for the scenario
  • 6.13.3 Scenario time line
  • 6.13.4 Recovery without DB2 Recovery Expert
  • 6.14 Recovery from Scenario E.
  • 6.14.1 Determine table and table space IDs
  • 6.14.2 Recover the table image from a backup using db2ox
  • 6.14.3 Determine the table space directory
  • 6.14.4 Backup the original table data file
  • 6.14.5 Lock the table
  • 6.14.6 Copy the table data file into the table space directory
  • 6.14.7 Backup the table space
  • 6.14.8 Obtain Redo SQL
  • 6.14.9 Run Redo SQL
  • 6.15 Command line versus GUI
  • 6.16 Summary of DB2 vs. DB2 RE PIT recovery methods
  • 6.16.1 Scenario B: SQL run since PIT
  • 6.16.2 Scenario C: SQL and DDL run since PIT
  • 6.16.3 Scenario D: PIT recovery with Referential Integrity
  • 6.16.4 Scenario E: PIT recovery using command line
  • Chapter 7. Dropped object recovery
  • 7.1 Scenario F: Recovery of a dropped table
  • 7.1.1 Scenario description
  • 7.1.2 Prerequisites for the scenario
  • 7.1.3 Scenario time line
  • 7.1.4 Recovery without DB2 Recovery Expert
  • 7.1.5 Situation before the table is dropped
  • 7.1.6 Recovering a dropped table using DB2 Recovery Expert
  • 7.2 Scenario G: Recover a dropped table using minilogs
  • 7.2.1 Scenario description
  • 7.2.2 Prerequisites for the scenario
  • 7.2.3 Scenario time line
  • 7.2.4 Before the table is dropped
  • 7.2.5 Creating a minilog for the DEPARTMENT table
  • 7.2.6 Recovering the dropped table using minilogs
  • 7.3 Scenario H: Recovery of a dropped table space
  • 7.3.1 Scenario description
  • 7.3.2 Scenario time line
  • 7.3.3 Prerequisites for the scenario
  • 7.3.4 Without DB2 Recovery Expert
  • 7.3.5 Situation before the table space is dropped
  • 7.3.6 Recovering a dropped table space using DB2 Recovery Expert
  • 7.4 Scenario I: Recovery of a dropped database
  • 7.4.1 Prerequisites for the scenario
  • 7.4.2 Recover a dropped database using DB2 commands
  • 7.5 Using DB2 RE to undrop a database
  • Chapter 8. Cloning a database or a table
  • 8.1 Scenario J: Cloning a database.
  • 8.1.1 Scenario description
  • 8.1.2 Prerequisites for the scenario
  • 8.2 Steps to clone the database
  • 8.2.1 Before we start
  • 8.2.2 Cloning a database using the DB2 Recovery Expert GUI
  • 8.3 Scenario K: Clone a specific table
  • 8.3.1 Scenario description
  • 8.3.2 Prerequisites for the scenario
  • 8.3.3 Without DB2 Recovery Expert
  • 8.4 Steps to clone the table using DB2 Recovery Expert
  • 8.4.1 Obtain DDL for the table from the source database
  • 8.4.2 Create the table at the target database
  • 8.4.3 Obtain IDs for the table at the source and target database
  • 8.4.4 Get the table data file image from the backup
  • 8.4.5 Change the database signature in the data file
  • 8.4.6 Place the new data file in the target database
  • Appendix A. Sample applications
  • The DEMOAPP application
  • Appendix B. Full log analysis reports
  • Reports for the EMPLOYEE table
  • Reports for all tables
  • Reports for a table with a BLOB column
  • Abbreviations and acronyms
  • Related publications
  • IBM Redbooks
  • Other resources
  • Referenced Web sites
  • How to get IBM Redbooks
  • IBM Redbooks collections
  • Index
  • Back cover.

Ejemplares similares