Simon Krenger

After installing the Operating System (in my case usually Red Hat Enterprise Linux or Oracle Enterprise Linux) and configuring all necessary parameters, one has to install the Oracle software. It is usually a good idea to use a response file to do this.

There are a few reasons to use a response file:

For Nagios, many, many Oracle plugins are available for checking database availability and performance. But if you just want to check if the instance is up and running (and not add more complexity), you can use the simple script provided here.

In an earlier post, I showed how to install SQL*Plus on Debian and based on that tutorial, I wrote a little shell script to query a database (I called it check_oracle_dual.sh):

There is always something that gets in the way. One problem I regularly stumble upon when installing a new Oracle 11g R2 installation is the following error when I try to start the database:

SQL> startup nomount;
ORA-00845: MEMORY_TARGET not supported on this system

So I keep this post mainly for my own reference when installing a new database on a Linux system.

This error comes up because you tried to use the Automatic Memory Management (AMM) feature of Oracle 11g R2. Well done, but it seems that your shared memory filesystem (shmfs) is not big enough. So let’s look at the steps necessary to enlarge your shared memory filesystem to avoid the error above.

In this article, I will describe the steps necessary to install Oracle SQL*Plus on a Debian host. I am using Debian 6.0.5 and will install the “Instant Client” package from Oracle (version 11.2.0.3). First, we will prepare the system for the installation, download the installation package, set all the necessary variables, start SQL*Plus and connect to an instance. So let’s get started…

Before we begin the package installation, we need to make sure the necessary prerequisite packages are installed. Oracle Instant Client requires the libaio package, so let’s install that:

Since most of our databases are not licensed with the Oracle Enterprise Manager Diagnostic Pack, we cannot use AWR (Automatic Workload Repository) and ADDM (Automatic Database Diagnostic Monitor). So we have to use the good old Oracle STATSPACK.

The goal of this article is to provide a quick reference for installing and maintaining STATSPACK for an Oracle database. It is based on the excellent “STATSPACK Survival Guide” of Akadia AG. If you need more information on STATSPACK, please refer to the Survival Guide or the Oracle documentation, since this article is only a really quick summary on how to install, configure and use STATSPACK.

On a few test databases, test managers often need to preserve certain states in the database. This is why we use daily datapump scripts to create exports for archival.

It is important to note that such scripts are never a replacement for a proper RMAN backup, but an easy way to preserve multiple states of a database and reuse data where applicable.

This batch file uses the expdp tool provided by Oracle and the 7-zip archiver to compress the exports for archival. The export tool itself creates a full export of the whole database (full=y). Also, the flashback_time parameter is specified to get a consistent export.

Ok, here is a quick trick that I just found out about earlier this week. I am currently in an Oracle Database 11g: Administration 11 course and learn many new things about database administration.

One thing you will definitely encounter when working with Linux is that it is not possible to scroll back though your SQL*Plus history with the arrow keys. If you try to do so, the following happens:

SQL> select owner, count(1) from dba_tables group by owner;

OWNER				 COUNT(1)
------------------------------ ----------
[..]
SYS				      673
SIMON				       88


7 rows selected.

SQL> ^[[A     " - rest of line ignored.
SQL> command "
SQL> 

Argh! Some kind of wild character sequence appears on the command line. A quick search shows that this is a common problem. One thing that regularly happens is that you enter a SELECT statement that returns too many rows. Because the terminal buffer only contains a certain number of rows, your query disappears and you have to retype it.

One thing DBAs regularly do is to gather information on the schemas in the database for reporting. So we want to know how many rows there are in the tables of the schema “SIMON”. When doing so, one is tempted to query the DBA_TABLES view:

SQL> SELECT table_name, tablespace_name, num_rows
  2  FROM dba_tables WHERE owner='SIMON' ORDER BY num_rows DESC;

TABLE_NAME                     TABLESPACE_NAME                  NUM_ROWS
------------------------------ ------------------------------ ----------
HUGE_TABLE                     DZ_DATA01                         8227990
[..]

However, if we query the table directly, we get a different result:

SQL> SELECT count(*) FROM simon.HUGE_TABLE;

  COUNT(*)
----------
   8230310

Why is that so? When reading through the description of the ALL_TABLES view, one finds the following note:

Well, I was quite busy before the holidays, but here is another post I just keep for my reference.

For each database, I believe it is important to automate database shutdown and database startup. This way, in case of an emergency, a systems administrator can start and stop database services without the need for a database administator. Oracle provides an excellent article on this topic, but the Oracle documentation is quite generic. So I hereby provide a step-by-step guide for Red Hat Enterprise Linux (RHEL).

In the last weeks, I had a few projects involving Oracle Advanced Replication and immediately stumbled upon the problem of not knowing which user and which instance was on which prompt. Instead of constantly issuing “SHOW USER” and “SELECT * FROM global_name“, I decided to add a few lines to my glogin.sql.

So before investing precious time, I fired up Google and found that other people also had the idea of changing the SQL*Plus prompt. I found the template for my own glogin.sql here and modified it so it fits my needs.

Note that my script does not display the GLOBAL_NAME of the databse, but only the INSTANCE_NAME read from v$instance. This means the prompt is usually a lot shorter:

repadmin@kdb3:SQL>

To change the prompt, append the following lines to your $ORACLE_HOME/sqlplus/admin/glogin.sql: