Sams oracle DBA survival guide oct 1995 ISBN 0672306816 pdf

PART I THE JOB OF THE ORACLE DBA PART II UNDERSTANDING HOW ORACLE WORKS PART III INSTALLING AND UPGRADING THE ORACLE SOFTWARE PART IV DEVELOPING A DATABASE ADMINISTRATION SCHEME... 57 Or

201 West 103rd Street Indianapolis, Indiana 46290

SURVIVAL GUIDE

Joseph B Greene

I came into this world knowing nothing Therefore, this book is

dedicated to all the people along the way who took the time to teach

me something.

FIRST EDITION

All rights reserved No part of this book shall be reproduced, stored

in a retrieval system, or transmitted by any means, electronic,

mechanical, photocopying, recording, or otherwise, without written

permission from the publisher No patent liability is assumed with

respect to the use of the information contained herein Although

every precaution has been taken in the preparation of this book, the

publisher and author assume no responsibility for errors or

omissions Neither is any liability assumed for damages resulting

from the use of the information contained herein For information,

address Sams Publishing, 201 W 103rd St., Indianapolis, IN 46290.

International Standard Book Number: 0-672-30681-6

Library of Congress Catalog Card Number: 95-67649

98 97 96 95 4 3 2 1

Interpretation of the printing code: the rightmost double-digit

number is the year of the book’s printing; the rightmost single-digit,

the number of the book’s printing For example, a printing code of

95-1 shows that the first printing of the book occurred in 1995.

Composed in New Century Schoolbook and MCPdigital by

Macmillan Computer Publishing

Printed in the United States of America

All terms mentioned in this book that are known to be trademarks

or service marks have been appropriately capitalized Sams

Publishing cannot attest to the accuracy of this information Use of

a term in this book should not be regarded as affecting the validity

of any trademark or service mark.

ACQUIS ITI ON S EDIT OR

PR O O F R E A D I N G

Nancy Price Brian-Kent Proffitt Erich Richter Susan D Van Ness Paul Wilson

IN D E X E R

Cheryl Dietsch

P RESIDENT AND P UBLISHER Richard K Swadley

A CQUISITIONS M ANAGER Greg Wiegand

D EVELOPMENT M ANAGER Dean Miller

M ANAGING E DITOR Cindy Morrow

M ARKETING M ANAGER Gregg Bushyeager

PART I THE JOB OF THE ORACLE DBA

PART II UNDERSTANDING HOW ORACLE WORKS

PART III INSTALLING AND UPGRADING THE ORACLE SOFTWARE

PART IV DEVELOPING A DATABASE ADMINISTRATION SCHEME

PART V THE DAILY ROUTINE

PART VI MONITORING THE DATABASE’S HEALTH

PART VII DEALING WITH PROBLEMS

PART VIII SUPPORTING USERS AND DEVELOPERS

PART IX ADVANCED ORACLE TECHNICAL FEATURES

The Concept of a Database Administrator 7

Variety of Responsibilities 8

Summary 11

2 The Database Administrator’s Job Description 13 Types of Database Administrator 15

The Full-Time Database Administrator 18

Developers Acting as Database Administrators 23

Scientists, Engineers, and Other Users as DBAs 28

Database Administrator Tasks 32

Is the Database Secure Enough? 33

Does the Database Perform Well Enough? 35

Is the Data Accurate? 37

Is the Data Stored in a Logical and Accessible Manner? 37

Interfacing with System Administrators and Other Support Staff 37

Understanding the Application Needs 39

Summary 42

3 History and Development of Databases and Oracle 43 Computerized Data Storage 44

The First Databases 46

Relational Databases 48

Oracle’s History 50

The Current Database Market 51

What Next? 52

Summary 53

4 Oracle and Its Environments 55 What Is Oracle? 56

Alternative Architectures 57

Oracle Development Tools Versus the Database 61

Oracle Utilities 63

Third-Party Products 66

Assembling the Parts into an Architecture 69

Summary 73

5 The Tools of the Trade 75

The Basics: SQL*DBA 78

The Next Generation: Oracle Server Manager 81

Personal Oracle7 for Microsoft Windows 82

The Command-Line Interface: SQL*Plus 88

Import and Export 90

Loading Data from External Systems: SQL*Loader 91

Third-Party Products 93

Locally Developed Tools 93

Summary 93

PART II UNDERSTANDING HOW ORACLE WORKS 95 6 How the Oracle RDBMS Works 97 Overview 98

The Oracle Processes 101

Memory and Speed 102

Disk Storage 104

Multiprocessing and Microsoft Windows Configurations 106

Summary 107

7 Oracle Memory Structures 109 Overview 110

The System Global Area (SGA) 112

The Program Global Area (PGA) 117

User Work Spaces 119

Summary 120

8 Oracle Files 123 File Locations 125

Data Files 127

Redo Log Files 129

Archive Log Files 131

Control Files 133

Initialization Files 133

Log and Trace Files 135

Summary 136

9 Oracle Processes 137 Overview 138

The System Monitor 142

The Process Monitor 144

The Database Writer 144

The Log Writer 147

The Archiver 148

The Recoverer 148

The Lock Writer 148

Dedicated Server Processes 149

Multi-Threaded Server Processes 149

SQL*Net Listeners 150

Parallel Query Processes 150

Oracle 7 for Microsoft Windows 151

Summary 151

10 Basic Oracle Database Objects 153 Overview of Storage and Access 154

Tables 159

Indexes 162

Views 164

Synonyms 166

Stored Procedures 167

Clusters 168

Sequences 169

Summary 169

11 Oracle System Privileges 171 Overview of Oracle Privileges 172

Overview of System Privileges 176

The User Privileges 178

The Developer Privileges 178

The “Any” Privileges 180

The Database Maintenance Privileges 185

The Monitoring Privilege 187

Typical Privilege Sets 188

The “Any” Privilege Sets 189

Summary 190

12 Oracle Object Privileges 191 Overview 192

Object Privileges 196

Using Dummy Object Owners 198

A Typical Privilege Scheme 199

Summary 203

13 Roles and Grants 205 Introduction to Grants 206

Introduction to Roles (Version 7 Feature) 209

Grants Without Roles 212

A Typical Privilege Scheme 212

Use of Scripts to Capture Privilege Sets 220

Summary 221

14 Backup and Recovery 223 The Importance of Backups 224

Overview of Oracle Backup Schemes 225

Archive Log or No Archive Log 228

Cold Backups 229

Warm Backups 236

Exports 238

Which Scheme to Choose 239

Rotating Backup Schemes 242

Automated Backup Schemes 245

What About Mirrored Disks? 247

Summary 248

PART III INSTALLING AND UPGRADING THE ORACLE SOFTWARE 249 15 The Life Cycle of an Oracle Database 251 Product Selection 254

Planning the Installation 255

Installation 256

When to Upgrade 257

Planning Upgrades 258

Upgrading the Oracle Software 259

Summary 260

16 Choosing Products and the Environment 261 Getting All the Pieces 262

Host-Based and Server-Based Architectures 268

Client-Server Architectures 271

Dealing with Vendors 274

Summary 276

17 Planning an Oracle Installation 277 Starting with Business Needs 279

The Installation and Configuration Guide 281

The README File 284

Oracle’s Recommended Layout 285

Calculating Data Space 288

Memory Area Planning 289

Process Planning 289

Developing Your Own Installation Plan 290

Some Good Reviewers 292

Summary 292

18 Oracle Installations 295 Overview 296

Starting with a System Backup 298

The Oracle Installer 299

Installing the Oracle Application Software 301

UNIX Installations 303

Creating a Database with the Installer 304

Dealing with Installation Problems 305

Manually Creating a Database 307

Summary 309

19 Planning an Oracle Upgrade 311 Overview 312

Storing the New Software 314

The Importance of the README File 314

Changes Needed in the Database 315

Other Factors to Consider 315

The Backout Plan 317

Lining Up Support 318

Summary 319

20 Oracle Upgrades 321 The Oracle Installer: To Use or Not? 323

Another Backup Lecture 324

Loading and Linking the New Software 324

Upgrading the Database 325

When Problems Occur 325

Summary 326

PART IV DEVELOPING A DATABASE ADMINISTRATION SCHEME 327 21 The Administration Scheme 329 What Is a DBA Scheme? 330

Technical Factors to Consider 333

Matching User Requirements 335

Preparing for the Future 336

Summary 338

22 Laying Out a Database 339 Overview 340

Data Files 341

Control Files 344

Online Redo Log Files 345

Archive Log Files 346

The Configuration Process 346

Expansion of the Database 348

Summary 349

23 A Routine Maintenance Schedule 351 Overview 352

Starting with User and System Processing Schedules 355

Types of Activities 357

The Daily Schedule 359

The Long-Term Schedule 360

Summary 361

24 Developing Scripts to Automate Tasks 363 Automation of DBA Tasks 365

SQL Scripts and System Scripts 367

Automatic Job Submission Utilities 373

Developing and Testing Scripts 377

Monitoring the Results 378

Summary 379

PART V THE DAILY ROUTINE 381 25 The “Typical” Day 383 Scheduled Events 386

Monitoring 386

User Support 387

Problems 388

If There Is Any Time Left 390

Summary 391

26 User Account Maintenance 393 User Maintenance and the Security Scheme 394

Using System Logon IDs for Access 396

Adding New Users to the Database 399

Changing User Access Rights 402

Deleting Users from the System 406

Temporarily Disabling Users 407

Summary 408

27 Tablespace Maintenance 409 Care and Feeding of Tablespaces 410

Monitoring and Planning 416

Typical Problems and Their Solutions 418

Summary 422

28 Table and Index Maintenance 423

Care and Feeding of Tables and Indexes 424

Monitoring Tables and Indexes 434

Typical Problems and Their Solutions 436

Fragmentation 442

Summary 443

PART VI MONITORING THE DATABASE’S HEALTH 445 29 The Health of a Database 447 What Is a “Healthy” Database? 448

Monitoring Programs 451

Auditing 454

Tuning 455

Summary 455

30 Routine Monitoring 457 A Routine Monitoring Program 458

Scripts and Reports 460

Utilization Monitoring 462

Tuning Monitoring 465

Security Monitoring 470

Configuration Monitoring 474

Third-Party Tools 477

Summary 478

31 Auditing 479 Overview 480

Oracle Auditing Events 483

Auditing and Performance 491

Auditing as Part of Security Monitoring 491

Deciding What to Audit 492

Summary 494

32 Tuning the Database 495 What Is Tuning? 496

What Can You Control? 498

Host Computer Indicators 504

Oracle Resource Contention 506

A Tuning Checklist 513

Summary 514

33 Looking Toward the Future 517 Knowing Where the Database Is Going 518

When More Is Needed 522

Proving Your Case 523

Summary 527

PART VII DEALING WITH PROBLEMS 529 34 When Problems Occur 531 Routine Requests, Problems, and Real Problems 533

Classifying the Problem 536

Resources to Identify the Problems 539

Unknown Problems and Approaches 541

Supporting Resources 542

The Ten Most Common Problems You’ll Face 543

Service Level Agreements 544

Summary 545

35 Space Problems 547 Identifying the True Problem 548

Cleaning Out Tablespaces 551

Expanding Tablespaces 553

Compressing the Number of Extents 555

Alternatives: Reducing Data Storage 559

Keeping the Data Definition Language (DDL) 560

Summary 560

36 Instance and Application Crashes 563 Tracing the Problem 564

Log Files Can Help 566

Operating System Conflicts 569

Expanding Oracle Resources for Applications 570

Reducing Oracle Resources for Applications 571

When to Call Oracle 571

Summary 573

37 When the Database Is Too Slow 575 When Is a Database Too Slow? 576

Managing User Expectations 578

Checking Tuning of the Database 579

Application Tuning 580

When Additional Capacity Is Required 581

Summary 583

38 Troubleshooting Checklist 585 Summary 589

PART VIII SUPPORTING USERS AND DEVELOPERS 591

Overview 594

Normalization and Table Design 597

Table Design Modifications for Decision Support 600

When and How to Use Indexes 601

Naming Conventions 604

Summary Tables Versus Views 606

Sizing Tables 606

Sizing Indexes 609

Summary 610

40 Query Optimization 611 Factors Designers Can Control 613

The Rule-Based Optimizer 616

The Cost-Based Optimizer 617

Execution Plans 619

Hints 622

Indexes 624

General Guidelines 624

The Value of Experimentation 626

Summary 626

41 Keeping Current as a DBA 629 The Changing Environment 631

Training Vendors 632

Books 634

A Test Instance 635

The Internet 635

User Groups 637

Summary 638

PART IX ADVANCED ORACLE TECHNICAL FEATURES 639 42 Rollback Segments 641 Introduction 642

Special Storage Considerations 644

Common and Confusing Error Messages 645

Setting Up Rollback Segments 647

Summary 648

43 L o c ks 649 Overview 650

Types of Locks Applied 651

Freeing Locks 653

Determining When an Application is Waiting for a Lock to Release 653

Summary 654

44 Parallel Processing Options 655 Types of Parallel Processing 657

When to Use Parallel Processing 658

Distributed Databases Versus Parallel Servers 658

Multi-Threaded Servers 659

Asynchronous Database Writers 660

Parallel Query 661

Parallel Recovery 661

Summary 662

45 Packages, Procedures, and Triggers 663 Software Stored in the Database 664

The Object-Oriented World 666

Trigger Types and Uses 667

Database Procedures 668

Database Packages 670

When to Use Packages, Procedures, and Triggers 671

Summary 671

46 Client-Server and Networking 673 What Is Client-Server? 674

Typical Client-Server Architectures 678

Tricks to Administering a Client-Server Database 679

Distributed Databases 680

Summary 680

47 Where To Next? 681 The Oracle Environment 682

The DBA’s Job 683

Tips to Make Life Easier 684

The Future 685

48 Oracle Workgroup Server and Oracle 7.2 687 First Impressions of the Workgroup Server Concept 688

Oracle 7.2 690

Rumors and Gossip About Oracle 8 691

Summary 691

APPENDIXES 693

Object Creation Commands 696

Object Modification Commands 698

Object Deletion Commands 699

B Glossary of Terms 701 C SQL*Plus Features 705 Calling SQL*Plus 706

Output Formatting 706

Working with SQL Files 708

SQL*Plus Versus SQL*DBA 709

D SQL*DBA Features 711 Command Line Versus Screen Mode 712

Menu Interface 712

Monitors 713

Killing User Sessions 713

Oracle Server Manager 713

E SQL*Loaders 715 Using Load Tables and Population Scripts 716

Fixed Column Versus Delimited Formats 716

An Example Control File 717

Useful Optional Parameters 717

F Import and Export 719 Command Line Versus Interactive 720

Import Parameters 720

Requirements for Running Import 721

Oracle Export 721

An Export and Import Example 721

G Where to Get More Information 725 Conventional Addresses 726

FTP Sites 726

World Wide Web Pages 726

Newsgroups 726

Some people lead highly focused careers I’m not one of those people Instead, I have

tried a number of different jobs, appreciating a variety of assignments and learning

new things This was how I got into Oracle I was working as a system architect and

MIS planner when someone needed to have a database management system I

ordered the system and, because I had worked with Oracle a little before for a test,

set up the system for them Once I set it up, I wound up maintaining the system

Then a strange thing happened People saw Oracle DBA work on my résumé and

started to ask for my services Even though I was qualified to perform a number of

other tasks and had actually spent more time working in those areas, I received

assignment after assignment as an Oracle DBA Some of these assignments were

extremely challenging, working on extremely large databases and integrating a

wide variety of client-server products into the environments Over time, I became

very comfortable as an Oracle DBA

Then I saw a request on the Oracle Internet Newsgroup for authors to write books

on Oracle I had always wanted to write a book, so I jumped at the opportunity

Practical people want to write books to further their careers or get a publication on

their resumes I just wanted to try something new and perhaps spread the

knowledge that I had been gaining through my consulting assignments I had

discovered that most of the places where I started up Oracle databases had similar

questions and needs that were not addressed by the books provided with Oracle

Don’t get me wrong I use the books that come with Oracle (electronic and hard copy)

all the time They are usually correct when you have a specific question on a specific

technical topic, but often lack an overall feeling for the job of the DBA They do a good

job as an encyclopedia, but do not present the big picture That is my goal for Oracle

DBA Survival Guide

Writing this book was definitely a challenge The folks at Sams (especially Rosemarie

Graham, the acquisitions editor) were very tolerant of my schedule demands and I

appreciate that

One of the things that I found to be most interesting as an author is the large number

of people who work on a book like this There are a large number of people who work

to acquire the books (in my case Rosemarie Graham), develop the book (Todd

Bumbalough), perform technical editing (Byron Pearce and Mark Gokman), pull

everything together (Nancy Albright), and perform all of the other services such as

preparing graphics, typesetting, and so forth (I don’t know these people’s names,

but thank them anyway)

Finally, there are a large number of people who I would like to thank for

contribu-tions that they have made to my development My Mom brought me into this world

and spurred me along all the way (by the way, Mom, I finished my book before youfinished yours) I would like to thank all my bosses and co-workers at Booz Allen &Hamilton for the professional development that they provided me—special thanks

to Ed Moore for teaching me to use graphics Finally, I would like to thank myfriends, and especially my wife Vicki, for being understanding about my not beingaround all those months while I was locked up in the study

Oracle DBA Survival Guide does not replace the reference books You still need tolook at the Installation and Configuration Guide specific to your operating systemand the version of Oracle when performing installations There are a number ofthings that change all of the time and you need these specific references Oracle DBASurvival Guide provides the overall concepts and some of the glue that enables you

to know which functions you should be performing and why Remember, the SQLLanguage Reference is always available to look up the exact syntax once you knowwhat you are trying to do I trust this book helps you get your job done moreefficiently

Introduction

Oracle DBA Survival Guide focuses on the job of the database administrator Much

of the text describes Oracle technical topics, but they are presented as backgroundmaterial to understand how to deal with problems and why things work the way they

do Practical experience and solutions to problems that I have encountered areinserted along the way The book is divided into many topics to enable you to focus

on those that are most important to your immediate situation You can save theremaining chapters for a cold winter night by the fireplace

This is a thick book Its usefulness on the job will be determined by how quickly youcan find the information that you need The following quick-access tools have beenused:

Part IV focuses on the development of a database administration scheme This is aturning point for the book because it marks where the reader has been presented

with the background material, tools, and alternatives needed to perform the job of

the DBA Here is where the focus shifts from the detailed “how do I” to the formation

of an overall vision of what is to be accomplished and how DBAs should form a clear

vision of the “big picture” for several reasons:

avoid duplicated or wasted effort (if you’re lucky, you may even get home ontime occasionally)

and systems, the DBA is often asked questions that relate to the overallflow of information in the business There are a lot of people who knowtheir niches very well, but few understand the functioning of the entireorganization The DBA is often asked to provide this understanding forcorporate data

exactly what is going on, exactly what is running, and exactly whereeverything is to be able to solve problems Often a problem in one place isactually only a symptom of a larger problem in another part of the system

Very few, if any, readers will read this book cover to cover in one sitting However,

the task descriptions, experiences, technical background topics, and touch of

philosophy (that I cannot help interjecting) provide the balance needed by Oracle

DBAs in the field

Oracle DBA Survival Guide is organized into nine parts, each designed to meet a

specific need that a reader may have

These chapters provide a warmup for the rest of the book Part 1 begins with some

introductory discussions on the job and the tasks associated with it An introduction

to the history of databases is provided for those who are curious about the origin of

these systems An overview of the Oracle family and how it fits into various

computer environments is followed by a discussion of the tools of the trade for the

database administrator

Although the primary focus of the book is on the job itself, a little theory is required

to ensure that the DBA really understands what is happening when the database

is operational Some of the topics are heavily theoretical, such as discussions on

Oracle memory structures Others are practical, such as the discussions on backupsand privileges All the chapters benefit DBAs by providing a true understanding ofwhat Oracle is and how it works.

What takes an almost insignificant percentage of the total time on the job, butcauses the most worry and concern? Installations and upgrades, in many cases.Installation of the software and creation of a new database is often the first task that

a DBA is assigned These tasks need to be performed correctly The keys stressed

in these chapters are the planning processes and checklist development that canmake this a relatively painless evolution

This is the part mentioned previously in which you take the technical foundationsand task descriptions explored earlier and form the overall scheme of operation foryour database Topics discussed include laying out where the files will be located,developing a routine maintenance schedule, and developing scripts to automatemany of the DBA tasks

These chapters focus on how to perform the tasks that make up the bulk of the day’swork for an Oracle DBA This includes user account maintenance, tablespacemaintenance, and database object maintenance

Databases can be very busy places Data flows in and out Developers are busilywriting new applications It is important to keep an eye on things within thedatabase so that you can detect situations that may lead to problems before theyactually become problems This part describes some monitoring tasks that you canperform to detect the common problems that grow within a database, such asrunning out of space, security violations, and a lack of certain key system resources

In the ideal world, everything works perfectly This is not the ideal world However,

a sound approach to dealing with problems—classifying, determining the cause,

forming solutions, and knowing where to get help—can reduce the number of gray

hairs received in the line of duty This part provides some techniques that can help

DBAs deal with problems when they arise

In many database installations, DBAs are seen as the gurus of data storage They

need to be able to provide guidance to developers and users about how to get the most

from their systems These chapters discuss some of the common subjects of

discussion

This part covers more detailed technical topics, such as locks and parallel

process-ing, that are not for everyone You can see these chapters as a place to go with

unusual questions or a series of topics that will lift you one level higher in the DBA

plane of existence

The appendixes contain command syntax, definitions, and useful lists that will

make the job of finding key data a little easier Almost all this information exists

somewhere within the Oracle documentation set However, these appendixes

reduce the number of books you have to look through for answers

Remember, you are not expected to read Oracle DBA Survival Guide in one sitting

and become an immediate DBA Do not be intimidated by the large volume of

material Most DBA tasks require information from only one or two chapters at a

time You can learn about the job gradually, as you need it

The Job of the Oracle DBA

P A R T I

Administrator

• The Database Administrator’s Job Description

• Histroy and ment of Databases and Oracle

Develop-• Oracle and Its Environments

• The Tools of the Trade

The W orld of Oracle

and the Database

Administrator

C H A P T E R 1

• The Concept

of a Database Administrator

• Variety of Responsibilities

Vendors often describe their “world”—in the case of Oracle, the term “world” seems

to be correct What started with a relational database management engine hasgrown into a number of development tools, networking products, computer aidedsoftware engineering (CASE) tools, and some complete, industry-specific packagessuch as Oracle Financials Part of the challenge faced by Oracle database adminis-trators (DBAs) is to determine what parts of this Oracle world they must supportand prepare themselves accordingly And so begins the challenge

With many complex topics, it is easiest to start with a brief overview that breaks thesubject down into smaller parts and then explore each of these componentsindividually Figure 1.1 graphically portrays an overview of the Oracle world andsome of the interfaces to it that are commonly found

Figure 1.1.

The world of Oracle.

Oracle CASE

Oracle Development Tools

Oracle Database Management System

Oracle Programmatic Interfaces

Third-Party Products

Industry Applications

The Oracle relational database management system (RDBMS) was the initialproduct offering and is at the center of most Oracle product installations Thisproduct is designed to provide the facilities to store and retrieve information in avariety of formats The data entrusted to Oracle is stored in a series of data files ondisk drives of the computer that is running the Oracle RDBMS If the RDBMS werelimited to a set of disk files, it would be similar to dBASE on a PC To work in large,multi-user environments, Oracle has had to add a number of items to the RDBMSarchitecture to provide needed services First, to increase speed on these largesystems and ensure consistency of the data, Oracle uses large areas of computermemory to store data, transactions, and control information Next, it implements aseries of background processes to perform part of the work of storing and retrievinginformation This also helps to reduce the complexity of each individual process andincrease the speed of processing, especially on computers with multiple CPUs Tosupport data integrity, Oracle keeps a separate record of transactions that are made

so that the data can be removed or rolled back if a transaction is canceled or the

system crashes In addition, there are several types of logs that record transactions

made with the purpose of enabling the data stored in the system to be recovered up

to the point of failure even if a disk drive is completely destroyed Finally, there are

a set of utilities that provide DBAs with an interface to the database engine and

enables them to perform common tasks such as system startup, data backup and

data loading It can be quite a complex system, but this is the secret of its power Only

a few DBAs have to be concerned with all the technical details of the product, and

this knowledge can be built up over time

Oracle’s next major product line is the series of tools that it provides to build

applications that interface with the RDBMS One of Oracle’s early product

direc-tions was to build a series of fourth-generation language (4GL) and graphical user

interface (GUI) tools to enable users to rapidly build applications that interfaced

with the Oracle RDBMS Some of you might be wondering what those terms really

mean Quite simply, Oracle built tools initially that used very high-level (close to the

English language) commands to access the database and build applications—the

4GL tools The GUI (often pronounced gooey) part of the story started with form- and

report-building tools that used Lotus-like menus and screen painters to build

applications Now, some purists may contend that this did not constitute a pure

GUI Well, one of the main themes in this book is not to dwell on theories and

academic debates For real-world purposes, this definition should be close enough

to the truth, if there is such a thing Anyway, Oracle has continued with products

that use pure GUI interfaces, such as those found in Microsoft Windows, the

Macintosh operating system, and the Motif environment In parallel with this, they

developed interfaces (Oracle pre-compilers) that can be used to access an Oracle

database from within a program written in a common programming language, such

as C or COBOL The key point to understand from this discussion is a product

direction of using a mix of high-level tools and programmatic interfaces to build

applications Many competing database vendors designed their application

devel-opment tools only around traditional programming languages such as C, COBOL,

etc Others designed their development tools only around the 4GL approach Oracle

has a tendency to support a wide range of tools, which has probably helped their

market share because each type of development tool is suited to a different type of

development effort

A third product line that has been around for several years is a set of computer-aided

software engineering (or CASE) tools These products are designed to enable you to

capture, in a graphical format, a representation of the application that you wish to

build for review and analysis There are a number of information engineering rules

and analyses that can be applied to the design to make it more sound If desired, you

can even instruct the computer to generate major pieces of the application

automati-cally

Another major product line currently being marketed is a series of applicationsdeveloped for certain industries This is designed to satisfy those organizations thatwish to purchase turnkey solutions from a single vendor These applications providemost of the common functions needed in such industries as financials (accounting,inventory, and so forth) and manufacturing (production scheduling and tracking).They, of course, are based around tables within an Oracle database, but they alsoconsist of a fairly complex array of programs that would take an organization sometime to develop on its own.

An important set of products in modern, multi-vendor, and client-server ments includes the networking products provided by Oracle and other vendors.These products allow developers to write applications on one platform (for example,

environ-a PC) thenviron-at environ-access denviron-atenviron-a locenviron-ated in environ-an Orenviron-acle denviron-atenviron-abenviron-ase on environ-another type of computer(for example, a UNIX server) It also allows different Oracle databases to exchangeinformation, both on an as-requested basis and through automatic synchronization

of specified data tables (the distributed database option) Finally, there are Oracleand third-party gateways that allow Oracle databases to communicate with othervendor’s databases, such as those from Sybase or IBM’s DB2

The final component in the world of Oracle comprises the interfaces provided toproducts that are not produced by Oracle Corporation In many installations, this

is a major part of the environment that the DBA has to understand and support.Companies such as Powersoft have made significant inroads with sophisticated yetsimple application development tools that have become standards in many organi-zations Therefore, it is important for a DBA to understand how these tools interface

to the database

This is the world of Oracle as it exists today It is interesting to note the directions

in which Oracle seems to be heading We can only guess these directions based oncompany statements and some applied logic, but here is my best guess Oracle hasplaced a strong emphasis on getting into the multimedia environment It seems toenvision an Oracle data storage utility as the basis for distributing multimediaservices, such as on-demand television programs Another direction seems to beacquiring and/or developing tools to compete in the object-oriented development toolenvironment with Powerbuilder A final observation is that Oracle, and most otherRDBMS vendors, seem to be moving towards the capability of storing objects (blobs

of any type of data such as X-ray images, songs, or videos) within their database.Although many smaller vendors have designed pure object-oriented databases,Oracle and other major RDBMS vendors seem to be migrating to object orientationgradually

Before starting work as an Oracle database administrator, it is interesting to

consider how this job came into being Early data storage mechanisms, such as tape,

card decks, and flat files were owned and maintained by the programmers who

developed the application (only they understood how these beasts were put

to-gether) Organizations tired of writing search and maintenance routines for each

new application, and data set sizes grew, especially those stored online on magnetic

disks Specialized software packages designed to manage stored data were

devel-oped Over time, the complexity and utilities for these database management

systems grew This created the need for a database administrator who understood

the inner workings of these packages and could get the most out of them It also

created careers for many individuals

It is sometimes interesting as a consultant to guess the types of computers that an

organization has had in the past based solely on the job titles Personnel systems

tend to change very slowly and the job responsibilities may change, but the titles

remain IBM actually published a fair amount of literature to its mainframe

customers regarding recommended organizations for the data center These

orga-nizations tend to have groups such as operations support, technical support,

database administration, and operations All of these are headed by a separate

manager reporting directly to the data center manager (who often goes by the title

of director or chief information officer) Organizations that grew up with VAXes and

other minicomputers tend to have groups of operators (perhaps with a shift

supervisor, but not often), an all-powerful system administrator (or one per system

if you were lucky), and the database administrator This is a warning that you may

inherit a legacy and expectations based on what IMS, DB2, or RdB database

administrators did on another computer platform One of the goals of this book is to

provide you with some suggestions as to tasks that the Oracle DBA should be

performing, along with the justifications for these tasks

It is important to remember that you are becoming a specialist in the Oracle

relational database management system Having worked on Sybase, Informix,

dBASE, and other database management systems, I appreciate the differences

between the various systems Oracle’s sound market share and trends towards

down-sizing, right-sizing, client-server, and so forth should give you a warm fuzzy

feeling about future job security for talented Oracle DBAs However, never lose sight

of your position in the marketplace My brother spent a brief tour of duty as a

recruiter in the computer industry He related to me that one of the hardest parts

of that job was when someone with a family to support came to him after being laidoff The story usually went that they loved his work, felt his $80,000 salary wasjustified, but they had to convert from the old Unisys (or Wang or ) system and thedatabase on which he was an expert did not run on the new platform In one case,

my brother found that there were only two or three installations of that databasepackage left in the entire country Enough said—if you plan on making a living as

a database administrator, it is always wise to keep an eye to what is becomingmarketable in the industry

In the era of the large, corporate data center, the job descriptions were based onrecommended structures from the various vendors This usually included largestaffs full of managers, directors, shift supervisors, and other wonderful titles Manyorganizations moved toward departmental computer organizations and the like.This created a number of jack-of-all-trades positions where someone may have beenthe operator, the database administrator, the system administrator, the manager,and the janitor Now compound this with the trend toward inexpensive UNIX-basedcomputers, where individuals may act as their own computer staffs for theirworkstation or a small server This leads to a world where people ranging from full-time, highly-trained database professionals to mechanical engineers, who are toojunior to get out of the assignment, serve as database administrators This bookdeals with this wide range of needs and provides help for all those brave souls whocall themselves a DBA

Perhaps it would be useful at this point to discuss how some organizations derivethe responsibilities for the database administrator This could be useful to under-stand if you are given the opportunity to have input into the discussions of a realisticset of responsibilities for your given circumstances Recall that the IBM and DECliterature guided the establishment of job descriptions in many data centers in thepast The following list of factors that help determine the DBA job descriptionresults from observations during consulting:

are conducting, so that person will be DBA, system administrator, andoperator

com-puter staff for you

what they told us.

do it all

the DBA

Although I said that there is no one set of duties for a database administrator, I’m

going to take a shot at a list of such duties anyway Consider this list as food for

thought:

first) Depending on your local computer culture, the actual backups may be

performed by computer operations or other support staff (especially in large

data centers) However, regardless of who is issuing the backup commands,

the DBA had better be certain that the backups being performed will

support recovery in the event of a loss of data

are stored in which file and on which disk drive)

that access the database

work with (not against) the database management system

develop-ment technologies

Where do you fit within the realm of possibilities? Consider some of these types:

than the database itself (yes, this is a mainframe shop)

administra-tive processes

database administrator)

ex-pected to have the background to be able to answer difficult questions)

packages

in the C programming language, and software developer

the Oracle database and all development tools

repositoryWith all that said, remember that the exact tasks you are asked to perform may vary,but it is important to have agreement by all parties what those tasks are and thelevel of service that you will be providing If you have other responsibilities that takepriority, make sure everyone knows that before problems come up

This chapter was a quick philosophical overview of where this book is headed It

stressed the book’s philosophy that it should focus on the Oracle DBA job itself The

Oracle relational database management system (RDBMS) was the initial product

offering and is at the center of most Oracle product installations It also was the first

of many discussions in this book where you will explore a variety of options as

opposed to one simple path With the wide range of hardware platforms, versions,

and user environments, it is impossible to lay out one simple “cookbook” approach

to Oracle database administration Instead, you will learn the key principles of

being a DBA and working with Oracle that should allow you to find the correct path

in your own particular world Now, onto the rest of the book!

C H A P T E R 2

• Types of Database Administrator

• Database Administrator Task List

• Interfacing with System Administrators and Other Support Staff

• Understanding the Application Needs

This chapter challenges you to consciously consider the job of the database istrator and the possibilities of which tasks are performed by the DBA and which areleft to others All too often, this division of responsibilities just happens Perhapssomething goes wrong, so the most competent individual in the organization isassigned to ensure that it does not happen again Perhaps it has “always” been donethat way Take some time when reading this chapter to consider which ones should

admin-be done by the DBA, given your individual situation

First, the chapter presents some typical situations that I have encountered in myconsulting travels This material serves to present how others have arranged theirjob descriptions Then you will explore a list of tasks and what is involved with theseeach Finally, you will examine common threads that should be woven into alldatabase administration schemes It is important to remember that there is no oneabsolutely right solution Instead, you have to find the solution that fits yoursituation at a given moment Odds are that as technology progresses, the list of taskswill change, but that is no reason not to have a plan for today

Recall that in the days when ships were wood and men were iron, data was stored

in flat files There were no database administrators, although there were oftensenior programmers who kept track of the data stored on various files and tried toset standards for how and where information was stored Data was often stored inenormous decks of computer punch cards that were stored in large boxes Manypotential computer lovers may have turned away from the field after their deck ofpunch cards scattered onto the floor just as they were ready to run that job one finaltime

Once corporations got hooked on the idea of storing valuable corporate data oncomputers, money became available to store data on disk drives At that time, diskdrives with under 100M capacity sold for tens of thousands of dollars This createdthe beginnings of the database administrator job People were assigned to ensurethat data was not being duplicated, that it was stored in an efficient manner, andthat unnecessary data was purged

Corporate data storage became a full-fledged addiction Executives loved being able

to find information that had been locked away in paper files and to calculate costsand delivery schedules far faster than ever before In walked software vendors tofeed this habit They noticed that every data application had a large amount ofcommon code These routines included such basic functions as finding and retriev-ing a row efficiently and writing a new record They developed common routines inpackages that would be purchased, thereby improving development productivity

Organization responded well to these packages of data handling utilities that

became database management systems There were a number of different thoughts

on how to organize the data (hierarchical, relational, and others), and systems were

developed that implemented these different philosophies on different host computer

platforms As these little jewels became more complex, it became a full-time (and

fairly well-paying) job to manage this treasure chest of information The duty of the

database administrator was born In most cases, the DBA was a full-time computer

professional who devoted most of his time to maintaining the database

Then came departmental computing Various business organizations decided that

the central data centers were not responsive enough and they implemented their

own computer complexes, usually on minicomputers such as the DEC VAX Vendors

built many good database management systems for these platforms, and they

needed a DBA However, in many of these installations, the DBA had other

responsibilities, such as being the system administrator or handling some other role

within the smaller, departmental computer organization

Today, we have a mixed bag of database management systems, platforms, and

organizational structures (see Figure 2.1) The rise in the number of small (easily

fits on a desktop) UNIX computers that have substantial processing capacity

enables many small organizations to set up databases on multi-user computers that

were previously locked on one person’s PC running dBASE This also usually means

that the person who is the dBASE developer is often asked to become a DBA on this

multi-user system Of course, many DBAs still work in large central data centers

that are implementing Oracle on mainframes or larger UNIX servers The

depart-mental folks are also swapping their minicomputers for smaller servers that do

more However, it is often easier to change the hardware and software environment

than it is to alter the organizational structure Try to keep an open mind while

reading the next couple of sections Envision how you think it should be done in your

environment Make notes and try to effect changes when the opportunities present

themselves

It would be nice if the simple categorization structure described previously covered

all possible DBA job descriptions However, there are many nuances in the roles and

responsibilities that should be considered in light of your talents and the “culture”

found in your organization If nothing else, studying other people’s work

environ-ments is an interesting pastime When you are a consultant, you need something to

get you through certain routine assignments

So what variables differentiate the various DBAs out there in the field? The needs

of the individual business units drive the DBA job description There are probably

as many variables as there are organizations, but for the most part, I have found thefollowing dominate:

Operations Operations Support

Departmental Computer Facilities

Departmental Hosts/Servers

Users

System administrator Database administrator

Project-Oriented Computer Systems

Mini Servers/Workstations

Users

System/Database Administrator Owner

The first factor, size of the system maintained, is one of the most interesting when

dealing with Oracle systems Oracle has developed versions of its software to run on

everything from stand-alone PCs to mainframes Reading forums such as the Oracle

newsgroups on the Internet, one gets an appreciation for the fact that different

environments face different problems The larger systems tend to have full-time

DBAs who worry more about tuning and disk space management The smaller

installations tend to worry about system capacity and have part-time DBAs Now

that there is a personal version of Oracle running under Microsoft Windows, there

are some people who act like dBASE developers and also act as DBA (sort of) for their

personal Oracle instance

The next factor to consider is the percentage of time available to you to perform the

DBA tasks Although this is often determined by the size of the database

(specifi-cally the number of tables and users versus the disk storage size), other factors such

as the amount of changes, technical complexity, or amount of support required by

the user community may shape the decision The key to remember is to keep the

percentage of your time available for the DBA job consistent with the tasks that you

agree to perform No one wins if you (or your manageability) commit to and cannot

perform critical tasks

Another variable that you need to have agreement on when committing to perform

database tasks is the level of expertise on the database package that will be expected

of you Many installations purchase commercial applications based on the Oracle

database and hire consultants to plan and install the system The in-house DBA is

merely responsible for performing backups, administering user accounts, and

monitoring utilization At other installations, DBAs are expected to do all the

design, planning, and implementation They are often expected to be a fountain of

wisdom on all subjects related to Oracle The trick here is to ensure that your

training and access to Oracle resources matches the expectations of you It is too

easy for your company to send you to minimal training and give you little

opportu-nity to keep up with technical topics via seminars, yet expect you to know

everything It is also important to emphasize the continuing education function

because the technology continues to change at a rapid pace

A topic related to database expertise that needs to be defined is the level of support

the DBA will provide for developers Most of the routine tasks performed by the DBA

can be planned out and, to a fair degree, automated through the use of scripts and

other tools The greatest challenges that I have found involved supporting

develop-ers who are tuning to make that query 20 percent faster or use stored procedures for

the first time Also, if your testing program is good, it will usually be the developers

who find problems with the security scheme or bugs with Oracle software One of

these problems can take a few minutes or several weeks to solve Therefore, if you

are going to be asked to support developers, ensure that you are not booked 100percent on the routine tasks and that you are provided with resources, such assupport contracts, to get help when needed.

Another decision that an organization has to make when defining the DBA jobdescription is the amount of computer system support that the DBA has to provide

In typical mainframe shops, there is a cast of other supporting players to providesupport for system administration, security administration, and hardware support

In smaller UNIX shops, all computer-related work may be performed by a singleindividual who is also the Novell administrator and PC guru Ensure that adequatetime has been factored into the schedule for these functions If you are new to aparticular computer environment, ask someone who is performing a similar job oryour vendors to get some estimates on support time

Finally, it is interesting to review the specialization requirements placed on someDBAs I worked with one fellow on a very large Oracle data warehouse who spentmonths working on nothing but application and query optimization He knew somany little tricks about setting the order of the tables in a query that he could turn20-minute queries into 5-second performers This specialty took a long time todevelop If your organization expects such specialization from you, ensure that youare provided the time and training to do the job

Perhaps the easiest type of DBA job to describe is that of the full-time DBA.Obviously, there will be a wide variation in the exact job description driven by theneeds of the business unit However, here’s a “typical” full-time DBA description togive you a feel for the job

The full-time DBA is usually involved with larger, more complex systems thatrequire a higher amount of care and feeding These shops also tend to depend less

on outsiders to install and plan their system needs Finally, because they tend tocome much closer to the capacity limits of the computer systems and tools, they tend

to find more problems with their systems and support tools such as databasemanagement systems These DBAs need to juggle a number of factors that arepulling on them to try and get what is needed done (see Figure 2.2)

One of the first things that needs to be hammered out is whether the full-time DBA

is responsible for operational systems, development support or both It is important

if you support both types of systems to have a firm agreement as to the relativepriorities of the two In most shops, operational problems take precedence overeverything imaginable It is usually the routine work that takes some juggling tobalance