Dba 101
Dba 101
Dba 101
Scope
This paper is intended to be an overview of some of the activities that a DBA might perform. We assume
that the reader has at least an introductory level of knowledge about both ORACLE and database
administration in general. Because of the limited amount of space allotted for a conference paper, only a
subset of DBA tasks will be addressed here.
The majority of the ORACLE version 8.0.5 information within this paper is based on the delivered
Windows NT and Digital Unix v8.0.5 software and may vary with your operating system version.
installed was not the correct version required for this Oracle installation. Everyone assumed that the
system administrator had upgraded the operating system.
Once you have verified that the operating system versions and patches are correct, read through the
installation instructions to verify that your system memory and disk resources are adequate for the Oracle
version you are going to use. Be sure to read through ALL of the instructions to ensure that you have the
appropriate answers for each question for which you will be prompted. Decide before you begin the
installation process whether you will want the Oracle installation to create a default database or not and, in
later versions of the software, whether you want Oracle to link the appropriate software, install, configure
and startup your listener and intelligent agent and install and configure a Names Server.
We believe that you should allow Oracle to create a small, default database during your software
installation for the following reasons:
• If the database creation succeeds, you will have probably verified your installation as well as proven
that a database CAN be built
• You will be able to “poke around in” the default database to see what roles, role composition, and
default users (along with their privileges) are being created by Oracle
• You will have a model of the naming conventions and files that Oracle feels are important – although
the sizing of these files may be unrealistic for your development or production needs
• You will have a small, test database that you can use as a “sandbox” to perform practice scenarios
for disaster recovery and to perform sanity checks if things fail to work correctly in another database
If the options are presented to you, we recommend that you allow Oracle to link the “application
software” and configure the listener and intelligent agent so that you will be able to see how Oracle
performed these tasks. Whether or not you will want to use the Oracle Names Server is another issue
(and probably another paper) but is outside the scope of this paper.
We suggest that you script everything you do – as you do it – so that you will be able to recreate your
actions later. After the software has been installed and proven to work correctly (by creating a default
database, etc.), you will want to create your own REAL database. Before you create your first database,
decide how many copies of the control file and how many redo log files you are going to want. You will
also need to determine the database block size for your database – the default from Oracle is 2k and
that’s generally just too small to be practical in anything other than a very small test database!
When you have completed creating your database, you will need to run the “CAT” scripts
(CATALOG.SQL, CATPROC.SQL, CATEXP.SQL, etc.). When you get a chance, take the time to
look at what the “CAT” scripts are used for. Be sure to always run CATALOG.SQL first and
CATPROC.SQL second and then any of the other “CAT” scripts in whatever order you want. If you
have already run CATALOG.SQL and CATPROC.SQL, you do not have to run them again to run any of
the other “CAT” scripts.
Your next step is to create one small rollback segment in the SYSTEM tablespace. You will not be able
to create any other objects or segments until you have created this rollback segment and brought it on line.
Once you have created the SYSTEM rollback segment, you will be able to create the other tablespaces,
rollback segments, etc. that you will want in your database. In the next section, we will look at how to
determine what your base tablespace configuration should look like.
3
Now, let’s take a look at each of these tablespaces and see what type of segments should be stored in
each. At first glance, it would seem like the SYSTEM tablespace is self-explanatory – a tablespace to be
used to store the objects that belong to the user SYSTEM. However, the SYSTEM tablespace should be
used to store only those objects that belong to the user SYS. Once you have created the first five
tablespaces listed in Table 1, we suggest that you alter the SYSTEM user to use the TOOLS tablespace
as the default tablespace and the TEMP tablespace as the temporary tablespace. We also suggest that
you alter the SYS user to point to the TEMP tablespace for sort operations. The commands you use are
as follows:
alter user SYSTEM default tablespace TOOLS temporary tablespace TEMP;
Why would you want to do this? To ensure that the only user who will be using the SYSTEM tablespace
is SYS and that the SYSTEM tablespace will not be used to store temporary segments during sorting
operations! Since, by default, Oracle creates users with their default tablespace as SYSTEM and their
temporary tablespace as SYSTEM, as you create each new user in your database, you will want to ensure
that you assign them a specific default tablespace and temporary tablespace. If you do not ensure that
SYS is the only user assigned to the SYSTEM tablespace, that tablespace will:
• Tend to get really fragmented
• Will have potentially severe contention against it
4
Okay, so the only user in the SYSTEM tablespace is SYS. The RBS tablespace (and you can have more
than one of these tablespaces) is used to specifically store rollback segments. If you have enough disks
and controllers and high rollback segment contention, you might even want to have two or more sets of
rollback segment tablespaces with the rollback segments spread evenly over them.
The next tablespace on the list is TEMP or TEMPORARY. As the name implies, this tablespace is
assigned to each user as the “temporary tablespace” that will be used each time a sort operation is
performed. What causes a sort operation? Any time a SQL statement includes “order by”, “group by”,
“union”, etc. operations, a sort will be performed. We want these sorts to be performed in a separate
tablespace that will be used specifically to store temporary segments so that other tablespaces will not get
fragmented. We have found that it is a really good policy to ONLY store temporary segments in a TEMP
tablespace. Do not put any other objects in there – even if they are viewed as “temporary” objects. You
can also have more than one temporary tablespace but each one should have a unique name that will help
indicate with whic h application it is associated. If you have a payroll application in your database in which
there is a great deal of sort activity, you might create an additional temporary tablespace named
TEMP_PAYROLL and assign it as the temporary tablespace for the PAYROLL_USER schema. We’ll
talk more about temporary segments and tablespaces defined as “temporary” later in this paper.
The fourth tablespace on our list is the TOOLS tablespace. As we mentioned earlier, you will want to
alter the SYSTEM default tablespace to point to the TOOLS tablespace. If you are licensed to use the
Oracle Developer or Oracle Discoverer or Oracle Web Applications software or another Oracle product,
you will install the base tables for these products either in their own schema area tablespaces or in the
TOOLS tablespace. You can also use this tablespace for third-party vendor products that require a
“SYSTEM” tablespace in which to house their objects.
Our fifth tablespace is USERS and can be used to provide an area where a user can create and store
small objects such as test tables or the prototype of a new application under development. If the
application begins to appear to be turning into a “real” application, you will want to move it from the
USERS tablespace to an area of its own – a set of DATA and INDEX tablespaces.
If your database is going to be used for one very small application, you would assign your schema
developer to the DATA tablespace and request that the developer use the INDEX tablespace to store
indexes for the application. If you are going to house many applications or one large application in the
database, you might want to create several tablespaces for data and indexes. The developer will have to
name the specific index tablespace to be used in the index creation script since, by default, Oracle will
place all objects created by a user in his or her default tablespace. In general, it is a good idea for the
developer to specify the tablespace for each table or index he or she creates, even if they want it in their
default tablespace. The DBA may decide to change the default tablespace of a user at any time and the
object may not end up where it was intended to go.
Let’s say that the PAYROLL application developer is working in the PAYROLL schema that was
created with the statement:
create user PAYROLL identified by payme
and was granted the Oracle -defined CONNECT role using the statement:
grant connect to PAYROLL
The creation statement for a basic table for the PAYROLL application might look like this:
create table PAY_SALARY (
Empname VARCHAR2(20),
Empnum NUMBER,
Job_Title VARCHAR2(10),
Salary NUMBER(9,2))
The creation statement for a basic unique index for the PAYROLL application might look like the
following:
create unique index PAY_SALARY_IDX
tablespace PAYROLL_INDEX
Notice that the table creation statement does not have a tablespace explicitly named while the index does.
By default, since the user was created pointing to the default tablespace PAYROLL_DATA any objects
that the PAYROLL user creates with no “tablespace” statement will be created in the default tablespace.
Notice also the granting of an amount of quota on each of the tablespaces to which the user will have
access. Even though the user has been granted the ability to create tables through the CONNECT role,
without quota being granted on a tablespace, the user could not create objects because there would be no
place for them to be stored.
CATDBSYN.SQL
An Oracle database uses memory-resident structures known as “x$” tables to store information
dynamically while the database is opened. Oracle provides “v$” performance tables for the DBA to view
to help in performance tuning. The metadata is stored in the Oracle data dictionary and has three levels of
information available. The three levels of information available are:
• USER_ – Any objects that the user personally owns
• ALL_ – Any objects to which the user has access
• DBA_ – All objects in the database (reserved for users who have been granted DBA privileges)
In an Oracle version 7.3 or earlier database, after you create the database, run the “CAT” scripts, create
the tablespaces and rollback segments, you will need to log on to the SYSTEM account and run the script
CATDBSYN.SQL that is generally located in the $ORACLE_HOME/rdbms/admin directory. This script
creates the data dictionary views so that the DBA can easily see the database metadata. Each user who
will be performing DBA tasks and has DBA privileges granted to him or her will also need to run this
script from their account.
In Oracle version 8.0.2 and higher, the approach used by Oracle is slightly different. Anyone who has the
DBA role assigned will automatically be able to “see” the data dictionary views.
PUPBLD.SQL
If you’ve ever logged onto a newly created database version earlier than v8.0.5, you may have gotten a
message stating that the “product user profile does not exist” with a notation to run PUPBLD.SQL.
What’s going on here? Why did you get this message?
From the early days of Oracle databases, you, as the DBA, have had the ability to block a user’s access
to the database by any method other than through an application. You could prevent a user from logging
directly into SQL*Plus and could block their ability to “Host” out to the operating system level. You could
even block their use of products like SQL*Forms and SQL*ReportWriter, etc. When a user attempted to
connect to the database using SQL*Plus or one of the early products, Oracle would check a table called
the PRODUCT_USER_PROFILE table to determine if the user was allowed to perform the action
requested. If Oracle went to check the table and it did not exist, the warning would be issued that the
table did not exist and Oracle would assume that, because there was no PRODUCT_USER_PROFILE
7
table, there was no requirement to block SQL access and the user would be permitted to log on to the
database from the SQL*Plus level. Of course, each user received the error message each time he or she
logged on to the database and you would receive irate calls from the users. If you were lucky, you either
remembered to run PUPBLD.SQL or you were the first person to log on to the database and the error
message was enough to “spur you to take action” and you’d run the script. Once the table was created in
the database and the appropriate views were created, you no longer got the error message because
Oracle now had a table that it could check to verify if the user should be permitted to access the database
through SQL*Plus or any other designated Oracle product.
Over the years, the complexion of what you can block and what you can’t block has changed. However,
the need to run PUPBLD.SQL in your newly created database has remained until version 8.0.5 when
Oracle started to automatically run this script when it creates a default database. If you manually create
your database, you will still need to run PUPBLD.SQL. You can use this utility to block access to SQL,
PL/SQL, and SQL*Plus commands including blocking one specific user or an entire group of users from
being able to reach the operating system level from within an application or from the SQL*Plus command
line. This utility is a way to enhance your database security but should be used with caution since you
might inadvertently block someone’s access when that access is really required for the person to perform
his or her job.
HELPINS.SQL
Up until Oracle version 8.0.5, if you wanted to provide online information about SQL and SQL*Plus
commands, you could run the script HELPINS.SQL to build the information area. You could then just
type “help <subject>” at the SQL*Plus command line and receive information immediately. You can still
do this with versions of Oracle earlier than 8.0.5. We have both found this feature very helpful and
appropriate to use in a development environment. We do no recommend that you install the help utility in a
production database since no one should be doing development there and there is a certain amount of
storage resource used with the utility.
If you type “help” in an Oracle version 8.0.5 database on a Windows NT platform, you will receive the
following message:
SQL> help
from DBA_USERS
The results from a default database created in version 8.0.5 on a Windows NT system were:
USERNAME
8
------------------------------
SYS
SYSTEM
ORDSYS
DEMO
DBSNMP
SCOTT
MDSYS
7 rows selected.
After you have determined the usernames, you will want to find out what privileges each user has been
granted in your database. Most of the users listed above have been granted CONNECT and usually
RESOURCE privileges. The MDSYS user was not granted any Oracle -supplied roles but, instead, has
been granted 90 system privileges and owns 21 procedures. The problem with the default users created
here are two-fold:
1. The RESOURCE role that is supplied by Oracle explicitly grants UNLIMITED TABLESPACE
privilege to the user who has been granted this role. This privilege means that a user can override any
assigned quotas and place objects anywhere in the database that he or she desires – even the
SYSTEM tablespace.
2. The default password – that may not be permitted to be changed – is very easily guessed. For
example, the DEMO password is “demo” and the MDSYS password (with 90 system privileges
available) is “mdsys”. The only passwords that differ from the usernames are SYS
(change_on_install), SYSTEM (manager), and SCOTT (tiger) that are all well documented and well
known.
You will need to determine if the default users that have been supplied are necessary in your production
database and if their passwords can be changes. SYS, SYSTEM, and SCOTT can all be safely modified
and we strongly urge you to do so as soon as possible after your database has been created. The
DBSNMP user is used by the intelligent agent to perform tasks within your database from a remote
console. In earlier versions of Oracle, the DBSNMP user has been granted the DBA role and may or
may not be able to work correctly if you change its password. This can pose a severe security problem.
What We Do Daily:
General Monitoring
LISTENER.LOG
The SQL*Net listener generates a log when it is started and writes to the log – either with a great deal of
information or minimally depending on what level of logging has been enabled. With the minimal message
information enabled on a Net8 listener, the information that is provided shows when the listener was
started, the ports being listened on, the machine on which the listener is running, etc. A sample entry looks
like the following:
TNSLSNR80 for 32-bit Windows: Version 8.0.5.0.0 - Production on 25-SEP-98 14:24:30
If you enable logging at a more intensive level, more information will be written to the log but more
overhead traffic will be incurred. We recommend you periodically check your LISTENER.LOG for
errors or when you seem to be encountering SQL*Net problems. Note that earlier versions of SQL*Net
will give different log information. The only way to remove a too-large listener.log is to stop the listener
10
process, delete the log file and restart the listener process. If you rename the log file, Oracle will continue
to write to the renamed file.
Monitoring Extents
For versions of Oracle earlier than 7.3.3, we, as DBAs, had to keep track of how many extents had been
allocated in a table or index. We feared that we would “blow extents” and receive one of the dreaded
error messages with ORA-01650 through ORA-01655 with the message “unable to extend …”. Let’s
talk a bit about what values we see for the parameter MAXEXTENTS and why there’s been a problem
with these values. Let’s also talk about why we still should be monitoring what our MAXEXTENTS are
set to and what our actual extent values are.
When you create a default Oracle database, what is the block size used by Oracle? If you answer “2k”,
you are correct. Now, how many rows of header information can a 2k block hold? If you answer “121”,
you are right again. So, for a 2k block size database, what is the maximum number of extents that you can
have prior to version 7.3 of the RDBMS? If you answer “121”, you are really on a roll! Hmm. Do we
see a correlation here? Of course! Now, if a 2k block size database can support 121 rows of header
information and 121 MAXEXTENTS per object, how many extents can a 4k database support? The
answer is 249. For an 8k block size, the maximum number of extents is 505. As you increase the
database block size, the number of maximum extents that you can have increases.
In version 7.3, the software has been modified to enable the header block to also extend so you can
actually have as many extents as your operating system will support and you can create your table with
MAXEXTENTS UNLIMITED instead of stating a number if you so choose. However, if you do not
specify a MAXEXTENTS value when you create a table and you have not specified a MAXEXTENTS
value when you created the tablespace where the table will be stored, the MAXEXTENTS value that will
be assigned for the table will be the default maximum extent limit based on the block size for that
database. For example, let’s create a tablespace in an 8K block size database as follows:
SQL> create tablespace mY_TS
Tablespace created.
We have not specified a MAXEXTENTS value. Now, let’s create a table and see what the default value
for MAXEXTENTS will be.
SQL> create table MY_TAB (Ename varchar2(20), Empno number);
Table created.
Next, we’ll select the values from user_tables and see what our MAXEXTENTS value is by default.
SQL> select Table_Name, Initial_Extent, Max_Extents
2 from USER_TABLES
We see that the value for MAXEXTENTS is equal to the default value for an 8k block size database.
To monitor the growth of tables in a database, you can use the following script:
prompt CHECKING FOR FRAGMENTED DATABASE OBJECTS:
prompt
In this set of scripts, we check for any table or index with a number of extents exceeding 12. You can, of
course, set your threshold to whatever value makes sense for your environment. The idea is to keep track
of those tables that are growing and may reach a point where they will exceed the amount of extents
allocated for them.
want to control when changes are made and who makes them. You can use auditing to monitor who has
made use of a privilege that changes an object, but auditing won't tell you which object was changed. The
DBA_OBJECTS and USER_OBJECTS views contain a column called Last_DDL_Time. This column
contains the time that the object was last modified. However, ORACLE considers adding grants or an
index a modification to the object, so this field doesn't really reflect the last time the object itself was
changed. To find this out, look in the Timestamp column of the DBA_OBJECTS or USER_OBJECTS
view. This field is varchar2(75) so you will need to convert it to a date. Set up a batch job to run once a
day that runs the following SQL script:
col Owner format a20
from DBA_OBJECTS
This script will list all objects that have changed since the prior day, in owner order. The status column is
included because procedures, functions and packages are objects and can become invalid
when changed.
select
13
substr(sysdate,1,9) today
from dual
select
value dbname
from
v$parameter
where
name = 'db_name'
spool &tdy..&xdb
prompt
prompt
prompt
prompt
prompt
prompt
prompt
prompt
from dba_data_files
order by 2,1;
spool off
exit
This script creates a file with the name in the form of “DD-MON-YY.<database_name>” like 10-OCT-
98.MYDB and produces a report like the following:
Datafile Information for MYDB - 09-OCT-98
1 row selected.
1 MYDISK01:[ORACLE.MYDB]ORA_LOG1.RDO 3145728
2 MYDISK01:[ORACLE.MYDB]ORA_LOG2.RDO 3145728
3 MYDISK01:[ORACLE.MYDB]ORA_LOG3.RDO 3145728
3 rows selected.
-----------------------------------------
MYDISK38:[ORACLE.MYDB]ORA_CONTROL1.CON, MYDISK39:[ORACLE.MYDB]ORA_CONTROL2.CON,
MYDISK40:[ORACLE.MYDB]ORA_CONTROL3.CON
1 row selected.
6 rows selected.
have to create public synonyms. And the problem with public synonyms is that if you have two
applications in your database, and each one has a table named HOLIDAYS that contains different data
for each application, you can't create the same public synonym name for the two tables.
Second, you can't create stored procedures, functions or packages using the access privileges you get
from a role. So all your developers will have to have access granted directly. Because of this restriction,
it's generally a good idea in production to have a single userid that owns all the objects and the procedures
that access the objects.