The following command can be used to add a new redo log group to an existing database:

ALTER DATABASE testdb

ADD LOGFILE

GROUP 1 (‘/u01/oradata/testdb/redo1a.log’,'/u02/oradata/testdb/redo1b.log’) SIZE 100M;

This command will add a redo log group (Group 1) to the database testdb. The log file group will have two members which are located on two different disks uo1 and uo2.

In Oracle the Group number must be unique. So before creating the group it is vital that you check the existing group number and then increment that number by 1 to get your new group number.

It is possible to add further log members to redo groups.

The command below will add a member to GROUP 1.

ALTER DATABASE testdb

ADD LOGFILE MEMBER

‘/u03/oradata/testdb/redo1c.log’

TO GROUP 1;

Alter system kill session ‘SID, SERIAL#’;

So why should I need to kill an Oracle session.  There are many reasons why you might want to kill a session. To give you a few exmaple:

Scenario 1:  You want to shutdown a database and want to shutdown normally. But if any user is logged onto the database then you can not shutdown the database. So instead of using IMMEDIATE or ABORT options in your shutdown command you might just want to kill the offending session and carry on with your task.

Scenario 2: You might need to kill an Oracle session which stopped responding while you were executing a long running query and program

Scenario 3: You may want to kill a session initiated by an unauthorised person

As killing a user session is quite serious action, only privileged users can execute the command. If you have DBA role in your database or if you can connect as a DBA to the database than you can certainly execute the command.

The values for SID and SERIAL# can be found by querying v$session view. This view is also not available to every users in the database and you will need to login as a DBA or a privileged user who can access this view.

Here is a query that you can use to get these values.

select sid, serial#, schema#, osuser, machine, terminal from v$session;

From the output result you have to identify the offending oracle session, note their SID and SERIAL# and then execute the alter session command.

And that’s it, the selected user session will be terminated.

But for people who want to access an Oracle database that is not local and in a remote machine then you must need to install Oracle client in your machine. Even if You do not want to use SQL*Plus but want to use TOAD or SQL Developer or something like that, you still need Oracle client. Because internally these database access/development tools use Oracle clients software to connect to the target database.

So the most important thing to remember is, you must need Oracle client software in your machine if you want to connect to a remote Oracle database.

Installing Oracle client is not difficult. You just need to be a bit careful. The step by step instructions below should help you to install an Oracle Client in your machine. These instructions assume that you have downloaded the Oracle client software that you desire to install and unzipped the zip file into some folder.

To make the instructions easy to understand I’ll explain what I did here:

1. Downlaoded Oracle Client Software from Oracle (zip file win32_11gR1_client.zip). This file is almost 500MB.

2. Unzipped win32_11gR1_client.zip into C:\win32_11gR1_client folder. A sub folder called “Client” is created under folder  “c:\win32_11gR1_client”. Within the Client sub folder there is a file called setup.exe, this is the file I’ll run.

3. I want to install my Oracle Client in my D: disk drive.

System Requirement: Oracle client is not so much of a heavy software but still it needs significant amount of disk space. So make sure that you have at least 1GB free in your disk drive where you want to install your client.

You must need to define the tnsentry so that your Client knows where to connect.

Oracle client is now installed. But do not forget tosetup tour tnsentry in tnsnames.ora file. With the example installation above the file will be located in D:\oracle\product\11.1.0\client_1\network\admin.

The script first builds up the ALTER commands for all invalid objects and put (spool)   the list into an operating system file called templist.sql. The ALTER commands will be of the format

ALTER PROCEDURE HR.CALLPROC COMPILE;
ALTER PACKAGE SCOTT.PKG_TEST1 COMPILE BODY;
ALTER PACKAGE SCOTT.PKG_TEST1 COMPILE BODY;

Note above that I am using the schema name before the object name e.g. HR.CALLPROC). This is to make sure that we are re-compile the invalid object in its own schema. The list file templist.sql will be run against the database to run all these commands in one go.

Here is the script:

SET HEADING OFF
SET PAGESIZE 0
SET FEEDBACK OFF

PROMPT Re-compilation complete…
SET HEADING ON
SET FEEDBACK ON

The VIEW called all_objects will have all objects that the user have access to. So If you run this script logged in as SYS user then it will have access to everything in the database.

Running this script:

1. Copy and paste the script marked in italic above and give a name such as compile_objects.sql.

2. Using SQL*Plus logon to Oracle as a priviledged user

3. Run the script compile_objects.sql as

sql>@compile_objects.sql;

sql>sho error;

4. Repeat the command again to make sure if anything still remains Invalid

sql>@compile_objects.sql.

sql>sho error;

5. Now check your database to see if objects are all VALID by running this query:

SELECT owner, object_name, status, last_ddl_time FROM ALL_OBJECTS WHERE status=’INVALID’;

Also note “show error” will display only the error message for the last object it tried to compile. So if you still have objects not compiled then you need to run individual ALTER commands and run “sho error” command to check the error. The objects can be compiled only if they can be really valid.

The script first builds up the ALTER commands for all invalid objects and put (spool)    the list into an operating system file called templist.sql. The ALTER commands will be of the format

ALTER PROCEDURE CALL COMPILE;
ALTER PACKAGE PKG_TEST1 COMPILE BODY;
ALTER PACKAGE PKG_TEST1 COMPILE BODY;

Then the list file templist.sql will be run against the database to run all this commands in one go. Which means you just need to run this one script to re-compile all your invalid objects in your schema. Note that I am using here USER_OBJECTS – which is a VIEW owned by SYS user.

SET HEADING OFF
SET PAGESIZE 0
SET FEEDBACK OFF

SPOOL templist.sql

SELECT ‘ALTER ‘ ||
DECODE( object_type, ‘PACKAGE BODY’, ‘PACKAGE’, object_type) || ‘ ‘ ||
object_name || ‘ COMPILE ‘ ||
DECODE( object_type, ‘PACKAGE BODY’, ‘BODY’, NULL) || ‘;’
FROM user_objects
WHERE object_type IN ( ‘VIEW’, ‘TRIGGER’, ‘PACKAGE BODY’, ‘PROCEDURE’, ‘FUNCTION’)
AND status = ‘INVALID’;

SPOOL OFF
SET FEEDBACK ON

PROMPT Re-compiling Invalid objects…
@templist.sql

PROMPT Deleting the templist file…
HOST rm -rf templist.sql

PROMPT Re-compilation complete…
SET HEADING ON
SET FEEDBACK ON

Running this script:

1. Copy and paste the script marked in italic above and give a name such as compile_objects.sql.

2. Using SQL*Plus logon to Oracle user whose invalid objects will be compiled (example scott/tiger).

3. Run the script compile_objects.sql as

sql>@compile_objects.sql;

sql>sho error;

4. Repeat the command again to make sure if anything still remains Invalid

sql>@compile_objects.sql.

sql>sho error;

5. Now check your database to see if objects are all OK (status=VALID).

Also note “show error” will display only the error message for the last object it tried to compile. So if you still have objects not compiled then you need to run individual ALTER commands and run “sho error” command to check the error. The objects can be compiled only if they can be really valid.