Error libdb.so.2: cannot open shared object file when installing Grid Control

I’m writing this post due that I receive this question almost once a week regarding OEM installations.
If you see this error when installing your Oracle Enterprise Manager (Grid Control 10.2.0.3) at OEL 5 or RHEL 5:

/home/oracle/OracleHomes/oms10g/Apache/Apache/bin/httpd: error while loading shared libraries: libdb.so.2: cannot open shared object file: No such file or directory

Don’t panic, all you need to do is:

1. Connect as root
2. Run : ln -s /usr/lib/libgdbm.so.2.0.0 /usr/lib/libdb.so.2
3. Problem solved, for more information please refer to: http://download.oracle.com/docs/cd/B19306_01/relnotes.102/b15659/toc.htm#CJAHFHCJ

Source: http://oraclenz.com/2009/12/15/error-libdbso2-cannot-open-shared-object-file-when-installing-grid-control/

SHUTTING DOWN THE DATABASE

You may need to shut down a running database for some types of backups, for upgrades of software, and so on, and there are several ways to do this. The option you choose will affect the time it takes to shut down the database and the potential for needing database instance recovery upon restarting the database. The following sections cover the four available database shutdown command options.

The SHUTDOWN NORMAL Command

When you issue the SHUTDOWN NORMAL command to shut the database down, Oracle will wait for all users to disconnect from the database before shutting it down. If a user goes on vacation for a week after logging in to a database, and you subsequently issue a SHUTDOWN NORMAL command, the data-base will have to keep running until the user returns and logs out. The normal mode is Oracle’s default mode for shutting down the database.

The command is issued as follows:

SQL> SHUTDOWN NORMAL

or

SQL> SHUTDOWN

Here are some details about the SHUTDOWN NORMAL command:

• No new user connections can be made to the database once the command is issued.
• Oracle waits for all users to exit their sessions before shutting down the database.
• No instance recovery is needed when you restart the database because Oracle will write all redo log buffers and data block buffers to disk before shutting down. Thus, the database will be consistent when it’s shut down in this way.
• Oracle closes the datafiles and terminates the background processes. Oracle’s SGA is deallocated.

The SHUTDOWN TRANSACTIONAL Command

If you don’t want to wait for a long time for a user to log off, you can use the SHUTDOWN TRANSACTIONAL command. Oracle will wait for all active transactions to complete before disconnecting all users from the database, and then it will shut down the database.

The command is issued as follows:

SQL> SHUTDOWN TRANSACTIONAL

Here are the details about the SHUTDOWN TRANSACTIONAL command:

• No new user connections are permitted once the command is issued.
• Existing users can’t start a new transaction and will be disconnected.
• If a user has a transaction in progress, Oracle will wait until the transaction is completed before disconnecting the user.
• After all existing transactions are completed, Oracle shuts down the instance and deallocates memory. Oracle writes all redo log buffers and data block buffers to disk.
• No instance recovery is needed because the database is consistent.

The SHUTDOWN IMMEDIATE Command

Sometimes, a user may be running a very long transaction when you decide to shut down the database. Both of the previously discussed shutdown modes are worthless to you under such circumstances. Under the SHUTDOWN IMMEDIATE mode, Oracle will neither wait indefinitely for users to log off nor wait for any transactions to complete. It simply rolls back all active transactions, disconnects all connected users, and shuts the database down.

Here is the command:

SQL> SHUTDOWN IMMEDIATE

Here are the details about the SHUTDOWN IMMEDIATE command:

• No new user connections are allowed once the command is issued.
• Oracle immediately disconnects all users.
• Oracle terminates all currently executing transactions.
• For all transactions terminated midway, Oracle will perform a rollback so the database ends up consistent. This rollback process is why the SHUTDOWN IMMEDIATE operation is not always immediate. This is because Oracle is busy rolling back the transactions it just terminated. However, if there are no active transactions, the SHUTDOWN IMMEDIATE command will shut down the database very quickly. Oracle terminates the background processes and deallocates memory.
• No instance recovery is needed upon starting up the database because it is consistent when shut down.

The SHUTDOWN ABORT Command

The SHUTDOWN ABORT command is a very abrupt shutting down of the database. Currently running transactions are neither allowed to complete nor rolled back. The user connections are just discon-nected. This is the command:

SQL> SHUTDOWN ABORT

These are the details about the SHUTDOWN ABORT command:

• No new connections are permitted once the command is issued.
• Existing sessions are terminated, regardless of whether they have an active transaction or not.
• Oracle doesn’t roll back the terminated transactions.
• Oracle doesn’t write the redo log buffers and data buffers to disk.
• Oracle terminates the background processes, deallocates memory immediately, and shuts down.
• Upon restarting, Oracle will perform an automatic instance recovery, because the database isn’t guaranteed to be consistent when shut down.

When you shut down the database using the SHUTDOWN ABORT command, the database has to perform instance recovery upon restarting to make the database transactionally consistent, because there may be uncommitted transactions that need to be rolled back. The critical thing to remember about the SHUTDOWN ABORT command is that the database may be shut down in an inconsistent mode. In most cases, you aren’t required to explicitly use a RECOVER command, because the database will perform the instance recovery on its own.

■  Tip:  Oracle recommends that you always shut down the database in a consistent mode by using the SHUTDOWN or SHUTDOWN IMMEDIATE command and not the SHUTDOWN ABORT command before backing it up.

Listing 10-13 shows what happens when an attempt is made to put a database in a read-only mode after the SHUTDOWN ABORT command was used to shut it down first. Note that Oracle won’t put the datafiles in read-only mode until the database is manually recovered. (You’ll find a lot more information on recovery in Chapter 16.)

Listing 10-13. The SHUTDOWN ABORT Command and the Need for Instance Recovery

SQL> SHUTDOWN ABORT
ORACLE instance shut down.
SQL> STARTUP MOUNT
ORACLE instance started.
Total System Global Area       314572800 bytes
Fixed Size                       1236756 bytes
Variable Size                   99164396 bytes
Database Buffers               213909504 bytes
Redo Buffers                     5169152 bytes
Database mounted.
SQL> ALTER DATABASE OPEN READ ONLY;
alter database open read only
*
ERROR at line 1:
ORA-16005: database requires recovery
SQL> RECOVER DATABASE;
Media recovery complete.
SQL>

■ Note:  In all shutdown modes, upon the issuing of the SHUTDOWN command, all new user connection attempts will fail. Except for the SHUTDOWN ABORT command, all the other SHUTDOWN commands won’t require instance recovery upon database startup.

How to prevent users using TOAD connecting to Oracle server from their client

This is a discussion on How to prevent users using TOAD connecting to Oracle server from their client; Because of your database security, you don't want some client login to Oracle server using TOAD(or others software). This show how to create a system trigger to prevent the connection as you need:

CREATE OR REPLACE TRIGGER prevent_users_login AFTER LOGON ON DATABASE
DECLARE
    CURSOR cur_session IS
        SELECT PROGRAM, USERNAME, SCHEMANAME, OSUSER FROM v$session
        WHERE audsid=sys_context('USERENV','SESSIONID');
    rec_session cur_session%ROWTYPE;
BEGIN
    OPEN cur_session;
    FETCH cur_session INTO rec_session;
    IF SUBSTR(rec_session.program,1,4) = 'TOAD'
        AND rec_session.OSUSER IN ('user_a', 'user_b', 'user_c')
        AND rec_session.SCHEMANAME LIKE 'XYZ%'
    THEN
       
        RAISE_APPLICATION_ERROR(-20001, 'You are not allowed to login');
    END IF;
    CLOSE cur_session;
END;