Documenting the Database

8/9/2019 Documenting the Database

1/5

Documenting the Database

Recently there were several scientific articles published about the various space probesthey are sending to Mars over the next several years. The purpose of the probes is to map

possible landing sites and look for signs of subsurface water, to get the lay of the landfor possible manned expeditions planned in the future. Just as Mars is a distant, veryforeign and sometimes inhospitable place, a database system that is unknown to you canalso provide challenges if you are trying to get a handle on its layout, contents andproblems. As a purely logical entity it is remote from you, there is no database you canpick up and examine in your hands, you cant turn it over, open the cover and look at itsinsides except with the use of remote probes from various tools.

Documenting a database unfamiliar to you can be a daunting task if you have never doneit before. Luckily explorers have been there before and have gotten the lay of the landas far as databases are concerned so if we follow their trails we should be successful. As a

DBA or tuning professional or consultant what are the things we need to look for in adatabase?

The things we need to look for in a database fall into four broad areas:

1. Configuration data2. Logical structures3. Physical structures4. Application code

Lets examine each of these areas in more detail.

Configuration Data

Review of the first area, configuration, entails viewing parameters that detail the waymemory and other resources for the database are defined. In Oracle the configurationparameters are contained within the initialization parameter file and are documentedinternally in the V$PARAMETER virtual table. Oracle, in its latest incarnation has over900 separate parameters if you count both the documented and undocumented ones.Luckily except in rare cases the DBA or designer only needs to deal with about 30 ofthese at any one time.

The 30 or so parameters that the DBA or designer/developer need to be concerned withdeal with the physical placement of various files and structures, the size of variousmemory areas and the configuration of the various automatic tuning operations of thedatabase being examined.


2/5

Logical Structures

The second two areas, logical and physical structures are usually the easiest to plumb, allfull function databases provide roadmaps in the form of data dictionary tables within thedatabase itself which allow us to view the structures and their relations. For example

within the Oracle database there are logical views that provide us with data dictionaryinformation. Views are predefined queries that act like tables, in this case they are builtagainst the underlying so-called dollar ($) tables that actually make up the data dictionaryin Oracle (they are called dollar tables since they all (or nearly all) have names that end inthe dollar sign such as: TAB$, COL$, IND$.) Some examples of these views that let uslook at logical constructions are:

DBA_TABLESPACES

DBA_INDEXES

DBA_TABLES

DBA_ROLLBACK_SEGS

DBA_TAB_PARTITIONS

DBA_IND_PARTITIONS

DBA_TAB_SUBPARTITIONS

DBA_IND_SUBPARTITIONS

DBA_TAB_COLUMNS

DBA_IND_COLUMNS

DBA_CONSTRAINTS

DBA_CONS_COLUMNS

DBA_SEQUENCES

In Oracle, the database we are using for our examples, there are three level of theselogical views; DBA which shows all objects of the specific type in the database, ALL which shows all objects the current user has permission to view, and USER whichshows only those objects the current user owns. Of course the above listing is just a fewexamples, there are literally hundreds of these views that cover data types, types, andmany other structural items, however the ones shown are the top level views.

Many folks may disagree that tables and indexes are logical structures, however, they areplaced there in Oracle because they are contained within the logical structure known as atablespace and have no actual physical file (most of the time) that you can copy off onto aCD and say Here is the X table, or, Here is the Y index.

As far as logical objects we are concerned with the number, type and relation of thelogical objects to each other. Examples of areas of concern are:

1. How many tables and indexes are there?2. How many tables have no primary key/index?3. How many tables have no indexes?4. How many tables have too many indexes?


3/5

5. What types of indexes are we using?6. Are the tables and indexes using proper block sizes and storage parameters?7. How many tables/indexes are partitioned? How many partitions do they have?

How are they partitioned?8. Are the tables and indexes optimally placed in tablespaces that are spread across

the disk resources?9. How do our various tables relate to each other?10. Is the structure over or under normalized?11. What are the sizes of our tables and indexes?12. Are we using the right data types?

If we can answer the eleven questions presented above then we can easily determine ifour database is properly structured at the logical level. However, logical structure is justthe start, we must also be concerned with physical structures.

Physical Structures

Since the logical structures of the database are contained within the physical structures,we must also be concerned with the physical aspects of the database. Some examples ofviews that let us look at physical structures are:

DBA_DATA_FILES

DBA_TEMP_FILES

V$LOGFILES

V$CONTROLFILE

V$PARAMETER

V$FILESTAT

V$TEMPSTAT

In the realm of physical structures we are most concerned with proper placement of highIO files across the disk assets we have. We need to watch placement to prevent hot disksthat can cause performance bottlenecks. Of course most modern disk arrays automaticallymove files and even individual disk stripes to better balance IO and prevent hotspotting,but even with the best balancing available we need to still monitor data files to be sure wehavent overloaded them as far has high IO tables and indexes. One area that is oftenoverlooked is the IO generated in the temporary tablespace datafiles in Oracle. Thetemporary tablespace handles sorts, hashes and global temporary table operations. Toooften the DBA only monitors the number of sorts to disk and neglects the amount of hashand global temporary table operations which can result in a majority of IO operations in

the database when hash joins and global temporary tables are utilized.

The other major physical placement issues are the locations for the redo log files and thelocations for trace and dump files. We have seen improper redo log placement lead otsignificant database waits for log writes. We have also seen improper specification of thetrace and dump file location lead to lock up of the database when the location ran out ofspace.


4/5

The other side of the physical storage involves dealing with the system administrator todetermine what type(s) of RAID are being utilized, the stripe width and number ofphysical spindles being used and what other applications (if any) are sharing the diskarray with the database. Many times we see the DBA treating the disk array as a blackbox, this can be a grave mistake as how the disks are striped and mirrored has a direct

affect on the performance of the database system.

However, if you get the configuration, logical and physical areas all absolutely correctbut fail to properly understand the application or fail to ensure that the application code isproperly tuned then it is unlikely your database will perform to its ultimate potential.

Application Code

Unfortunately the DBA is usually the last to see application code. A DBA may not evenbe assigned until after an application is written and performs badly. Being able to beattheir way through the jungle of application code to find the problem areas is what

separates the DBBS (Database Baby Sitter) from the capable DBA. Oracle providesseveral views into the heart of the application allowing the DBA to view application codeand see statistics that tell the experienced DBA where problem code has been executedand gives them vital clues to correcting the tuning issues represented by the code.

The major views needed for SQL and application code analysis are:

V$SQLAREA

V$SQLTEXT

V$SQL_PLAN

V$DB_OBJECT_CACHE

V$SESSTAT V$SYSSTAT

V$WAITSTAT

V$PROCESS

V$TRANSACTION

V$SESSION_LONGOPS

DBA_SOURCE

DBA_TRIGGERS

DBA_VIEWS

By utilizing the V$SQLAREA, V$SQLTEXT and V$SQL_PLAN views the DBA ordeveloper can see how Oracle has executed a particular SQL statement. By utilizing thevarious statistic views the wait signatures of the database can be constructing showing thetypes of transactions that are causing the most problems within the database.

For a completely undocumented database the source code for stored objects (PL/SQL,Java) can be reverse engineered from the various DBA views.


5/5

Documenting the Database

Documents

Transcript of Documenting the Database