Creating standby database 10.1.0.4.0 using OMF

While creating a standby database on 10.1.0.4.0 , i ran in some trouble while performing the following RMAN statements :

RMAN> run{
ALLOCATE AUXILIARY CHANNEL dup1 DEVICE TYPE DISK
DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER;
}

First a channel will be allocated on which the duplication starts. The datafiles are places in the right location. But when it comes to the point where the duplicate action executes :

contents of Memory Script:
{
switch clone datafile all;
}
executing Memory Script

The following error is thrown :

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/28/2009 19:08:41
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-19625: error identifying file /u02/oradata/COREF/datafile/o1_mf_system_5fyfx677_.dbf
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

RMAN>

Here i could see that the filename which is called for , is indeed the correct one.

After some researching i found that there is a difference in the database version in which the performed actions take place.
I did set the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT , which actually should NOT be done in rdbms version 10.1.4.0. ( other versions you should , if appropriate )
Also , when performing a duplicate when the primairy database is using OMF , you should set the standby_file_management=AUTO as this will restore datafile using %u which will be converted in the correct name to be picked up by the script.

After setting the following parameters in the auxiliary pfile, the RMAN duplicate finished successfully.

db_name = COREP (- must be set to a name of the primary db_name)
db_unique_name = COREF (- must be set to a name different from primary db_unique_name)
standby_file_management = AUTO (- must set to AUTO)
db_create_file_dest = ‘/u02/oradata’ (- must be set)

Restore Datafile using RMAN backup

When for some reason a datafile is lost and RMAN is in place. You might want to recover the file using the RMAN restore option for restoring datafiles.

Here is a brief overview on how to proceed.

oracle@xxx: $ ls -ltr
total 1656572
-rw-r—– 1 oracle oinstall 20979712 Jul 11 06:00 temp01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 12 22:01 redo01.log
-rw-r—– 1 oracle oinstall 262152192 Jul 12 22:02 users01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 12 22:02 redo03.log
-rw-r—– 1 oracle oinstall 199237632 Jul 13 08:29 sysaux01.dbf
-rw-r—– 1 oracle oinstall 209723392 Jul 13 08:50 undotbs01.dbf
-rw-r—– 1 oracle oinstall 314580992 Jul 13 08:50 system01.dbf
-rw-r—– 1 oracle oinstall 536879104 Jul 13 08:54 xwiki01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 13 08:54 redo02.log
-rw-r—– 1 oracle oinstall 7094272 Jul 13 08:54 control03.ctl
-rw-r—– 1 oracle oinstall 7094272 Jul 13 08:54 control01.ctl

oracle@xxx: $ rm xwiki01.dbf

Here we are 1 datafile short !

oracle@xxx: $ ls -ltr
total 1656572
-rw-r—– 1 oracle oinstall 20979712 Jul 11 06:00 temp01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 12 22:01 redo01.log
-rw-r—– 1 oracle oinstall 262152192 Jul 12 22:02 users01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 12 22:02 redo03.log
-rw-r—– 1 oracle oinstall 199237632 Jul 13 08:29 sysaux01.dbf
-rw-r—– 1 oracle oinstall 209723392 Jul 13 08:50 undotbs01.dbf
-rw-r—– 1 oracle oinstall 314580992 Jul 13 08:50 system01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 13 08:54 redo02.log
-rw-r—– 1 oracle oinstall 7094272 Jul 13 08:54 control03.ctl
-rw-r—– 1 oracle oinstall 7094272 Jul 13 08:54 control01.ctl

First connect to your RMAN “catalog” and list backup to find the datafile number to restore.

oracle@xxx: $ $ORACLE_HOME/bin/rman

Recovery Manager: Release 10.2.0.1.0 – Production on Mon Jul 13 08:54:59 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

RMAN> connect target;

connected to target database: XWIKI (DBID=675473154)

RMAN> list backup;

using target database control file instead of recovery catalog

List of Backup Sets
===================

BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
82 Full 137.80M DISK 00:00:55 06-JUL-09
BP Key: 82 Status: AVAILABLE Compressed: NO Tag: TAG20090706T220341
Piece Name: /u04/backup/XWIKI/rman/backup_df_88_691538622.bak
List of Datafiles in backup set 82
File LV Type Ckp SCN Ckp Time Name
—- — —- ———- ——— —-
1 Full 2127473 06-JUL-09 /u02/oradata/xwiki/system01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
84 Full 76.31M DISK 00:00:59 06-JUL-09
BP Key: 84 Status: AVAILABLE Compressed: NO Tag: TAG20090706T220341
Piece Name: /u04/backup/XWIKI/rman/backup_df_86_691538622.bak
List of Datafiles in backup set 84
File LV Type Ckp SCN Ckp Time Name
—- — —- ———- ——— —-
5 Full 2127471 06-JUL-09 /u02/oradata/xwiki/xwiki01.dbf

..
…
..

BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
141 Full 6.83M DISK 00:00:00 12-JUL-09
BP Key: 141 Status: AVAILABLE Compressed: NO Tag: TAG20090712T220211
Piece Name: /u04/backup/XWIKI/rman/c-675473154-20090712-00
Control File Included: Ckp SCN: 2330680 Ckp time: 12-JUL-09
SPFILE Included: Modification time: 08-JUL-09

RMAN>

We know now that datafile 5 is the one to restore. Before we can proceed we need to put it offline.

RMAN> SQL ‘ALTER DATABASE DATAFILE 5 OFFLINE’;

sql statement: ALTER DATABASE DATAFILE 5 OFFLINE

RMAN>

Now that the datafile is offline , we are ready for the RMAN datafile restore.

RMAN> RESTORE DATAFILE 5;

Starting restore at 13-JUL-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=141 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=140 devtype=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: sid=149 devtype=DISK
allocated channel: ORA_DISK_4
channel ORA_DISK_4: sid=139 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00005 to /u02/oradata/xwiki/xwiki01.dbf
channel ORA_DISK_1: reading from backup piece /u04/backup/XWIKI/rman/backup_df_142_692056911.bak
channel ORA_DISK_1: restored backup piece 1
piece handle=/u04/backup/XWIKI/rman/backup_df_142_692056911.bak tag=TAG20090712T220151
channel ORA_DISK_1: restore complete, elapsed time: 00:00:16
Finished restore at 13-JUL-09

RMAN>

At this point we are not yet ready to put the datafile back online

RMAN> SQL ‘ALTER DATABASE DATAFILE 5 ONLINE’;

sql statement: ALTER DATABASE DATAFILE 5 ONLINE
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/13/2009 08:53:45
RMAN-11003: failure during parse/execution of SQL statement: ALTER DATABASE DATAFILE 5 ONLINE
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: ‘/u02/oradata/xwiki/xwiki01.dbf’

As this is an “old” datafile and not the up to date one, we need to recover the datafile to match the others. This can easily be done by executing the following.

RMAN> RECOVER DATAFILE 5;

Starting recover at 13-JUL-09
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
using channel ORA_DISK_4

starting media recovery

archive log thread 1 sequence 6 is already on disk as file /u03/oradata/xwiki/archiving/1_6_691685756.arc
archive log thread 1 sequence 7 is already on disk as file /u03/oradata/xwiki/archiving/1_7_691685756.arc
archive log thread 1 sequence 8 is already on disk as file /u03/oradata/xwiki/archiving/1_8_691685756.arc
archive log thread 1 sequence 9 is already on disk as file /u03/oradata/xwiki/archiving/1_9_691685756.arc
archive log thread 1 sequence 10 is already on disk as file /u03/oradata/xwiki/archiving/1_10_691685756.arc
archive log thread 1 sequence 11 is already on disk as file /u03/oradata/xwiki/archiving/1_11_691685756.arc
archive log thread 1 sequence 12 is already on disk as file /u03/oradata/xwiki/archiving/1_12_691685756.arc
archive log filename=/u03/oradata/xwiki/archiving/1_6_691685756.arc thread=1 sequence=6
archive log filename=/u03/oradata/xwiki/archiving/1_7_691685756.arc thread=1 sequence=7
archive log filename=/u03/oradata/xwiki/archiving/1_8_691685756.arc thread=1 sequence=8
media recovery complete, elapsed time: 00:00:03
Finished recover at 13-JUL-09

RMAN>

Now that the datafile is brought up to speed, we can put our datafile online again.

RMAN> SQL ‘ALTER DATABASE DATAFILE 5 ONLINE’;

sql statement: ALTER DATABASE DATAFILE 5 ONLINE

RMAN>

Recover deleted datafile on linux when instance is still running

When for some reason a datafile is lost while the database is still up and running, you are not lost !
You can easily recover the datafile as the database was using the datafile and therefor still has a file descripter pointing to the deleted datafile.
The datafile filesize is not returned as free space after deleting a file which is in use. Instead only the inode is removed and the deleted file “stays” to exist.
When the file descripter is closed, the deleted file is perminatly removed and free space is then given back. So when dealing with a running instance, the files are still in use and therefor recoverable by following these steps.

Here are the steps i follow to restore a datafile which was delete on a running database instance.

oracle@xxx:1001 $ ls -ltr
total 1656572
-rw-r—– 1 oracle oinstall 20979712 Jul 9 22:00 temp01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:01 redo02.log
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:03 redo01.log
-rw-r—– 1 oracle oinstall 262152192 Jul 9 22:03 users01.dbf
-rw-r—– 1 oracle oinstall 199237632 Jul 10 14:05 sysaux01.dbf
-rw-r—– 1 oracle oinstall 209723392 Jul 10 14:23 undotbs01.dbf
-rw-r—– 1 oracle oinstall 314580992 Jul 10 14:25 system01.dbf
-rw-r—– 1 oracle oinstall 536879104 Jul 10 14:27 xwiki01.dbf
-rw-r—– 1 oracle oinstall 52429312 Jul 10 14:27 redo03.log
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:27 control03.ctl
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:27 control01.ctl

A simple select on a table housed into our xwiki tablespace.

SQL> select * from t;

A B
———- ———-
1 john

SQL> exit

Now we remove the datafile which contains this data.

oracle@xxx:1003 $ rm xwiki01.dbf
oracle@xxx:1004 $ ls -i xwiki01.dbf
ls: xwiki01.dbf: No such file or directory

When logging into the database now , you might encounter some errors while performing transactions.
A select goes well , as this is “cached” , but an insert shows us there is a problem.

SQL> select * from t;

A B
———- ———-
1 john

SQL> insert into t values(2,’john2′);
insert into t values(2,’john2′)
*
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: ‘/u02/oradata/xwiki/xwiki01.dbf’
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Now we will search the process which is still using our datafile ( the database writer process dbw )

oracle@xxx:1005 $ ps -edf | grep dbw
oracle 1712 1534 0 14:35 pts/1 00:00:00 grep dbw
oracle 27691 1 0 Jul08 ? 00:00:03 ora_dbw0_xwiki

This will give us the proc which has the file descripter ( or file handle ) open to our lost file;

oracle@xxx:1006 $ ls -l /proc/27691/fd | grep xwiki01
lrwx—— 1 oracle oinstall 64 Jul 10 14:35 26 -> /u02/oradata/xwiki/xwiki01.dbf (deleted)

This number is our reference to our lost datafile and can be used to recover it.

oracle@xxx:1007 $ ls -l /proc/27691/fd/26
lrwx—— 1 oracle oinstall 64 Jul 10 14:35 /proc/27691/fd/26 -> /u02/oradata/xwiki/xwiki01.dbf (deleted)

We now create a symbolic link to it, so that the database is again able to adres the datafile which is managed threw its tablespace.

oracle@xxx:1008 $ ln -s /proc/27691/fd/26 /u02/oradata/xwiki/xwiki01.dbf
oracle@xxx:1009 $ ll
total 1131760
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:37 control01.ctl
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:37 control03.ctl
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:03 redo01.log
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:01 redo02.log
-rw-r—– 1 oracle oinstall 52429312 Jul 10 14:36 redo03.log
-rw-r—– 1 oracle oinstall 199237632 Jul 10 14:28 sysaux01.dbf
-rw-r—– 1 oracle oinstall 314580992 Jul 10 14:31 system01.dbf
-rw-r—– 1 oracle oinstall 20979712 Jul 9 22:00 temp01.dbf
-rw-r—– 1 oracle oinstall 209723392 Jul 10 14:28 undotbs01.dbf
-rw-r—– 1 oracle oinstall 262152192 Jul 9 22:03 users01.dbf
lrwxrwxrwx 1 oracle oinstall 17 Jul 10 14:36 xwiki01.dbf -> /proc/27691/fd/26

We now put our tablespace in read only mode so that we can restore the datafile.

SQL> alter tablespace xwiki read only;

Tablespace altered.

The datafile is not used anymore now , so we can start “restoring” the datafile back from our file descripter.
First we remove the symbolic link created earlier and copy the fd back to the correct datafile name.

oracle@xxx:1010 $ rm xwiki01.dbf
oracle@xxx:1011 $ cp -p /proc/27691/fd/26 /u02/oradata/xwiki/xwiki01.dbf

Now we see that our datafile is back with the correct size !

oracle@xxx:1012 $ ll
total 1656572
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:38 control01.ctl
-rw-r—– 1 oracle oinstall 7094272 Jul 10 14:38 control03.ctl
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:03 redo01.log
-rw-r—– 1 oracle oinstall 52429312 Jul 9 22:01 redo02.log
-rw-r—– 1 oracle oinstall 52429312 Jul 10 14:37 redo03.log
-rw-r—– 1 oracle oinstall 199237632 Jul 10 14:28 sysaux01.dbf
-rw-r—– 1 oracle oinstall 314580992 Jul 10 14:31 system01.dbf
-rw-r—– 1 oracle oinstall 20979712 Jul 9 22:00 temp01.dbf
-rw-r—– 1 oracle oinstall 209723392 Jul 10 14:37 undotbs01.dbf
-rw-r—– 1 oracle oinstall 262152192 Jul 9 22:03 users01.dbf
-rw-r—– 1 oracle oinstall 536879104 Jul 10 14:37 xwiki01.dbf
oracle@xxx:1013 $

We now can put our tablespace back to read write mode and test our insert again.

SQL> alter tablespace xwiki read write;

Tablespace altered.

SQL> insert into t values(2,’john2′);

1 row created.

SQL> select * from t;

A B
———- ———-
1 john
2 john2

SQL>

Good luck recovering :)

ORA-01031: insufficient privileges when connecting as sysdba

Yesterday i ran into a server which did not allow to connect with “sqlplus / as sysdba” ( or sqlplus “/as sysdba”) but would allow sqlplus sys as sysdba.
I needed the server to allow this as scripts are using this connect method to execute nightly database operations.

[DXP01] xxx:admin> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 – Production on Wed Jul 7 20:45:54 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

ERROR:
ORA-01031: insufficient privileges

Enter user-name:

After recreating the passwd files by using

orapwd file=$ORACLE_HOME/dbs/orapwDXP01 password=manager entries=5

And double checking the group membership of oracle were the users oracle should be part of the group “dba”.

[DXP01] xxx:admin> id
uid=1000(oracle) gid=1000(oinstall) groups=1000(oinstall),1001(dba)

I found myself with an SQLNET.ORA which causes this behaviour.

SQLNET.AUTHENTICATION_SERVICES=(NTS)

After commenting out this line i was able to connect as sysdba again.

[DXP01] xxx:admin> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 – Production on Wed Jul 7 20:57:05 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL>

ORA-01031: insufficient privileges when using EXP

Using an export OS script with a command similar to this:

exp “‘/ AS SYSDBA’” full=y file=export_SID.dmp log=export_SID.log statistics=none

This error suddenly came around.

EXP-00056: ORACLE error 1031 encountered
ORA-01031: insufficient privileges

After researching this error, i found that when the TWO_TASK parameter is set, Oracle tries to connect via Oracle Net.
This then will return an error while connecting using $OPS login of “/” , which is done in my case.

after unset this variable the problem was solved !

unset TWO_TASK

Dataguard returns ORA-16664: UNABLE TO RECEIVE THE RESULT FROM A DATABASE

After succesfully creating a standby database using RMAN duplicate on a primairy site 11.1.0.6 .
The logfle shipping works ok, but the dg_broker seems to have a problem which i couldn’t pin down.
The Dataguard broker was configured using Enterprise Grid Control using the add standby database option “Manage
existing standby database”. The configuration steps were preformed successfully, however this error is shown for the standby database.

The Data Guard status of stby is Error ORA-16664: unable to receive the result from a database.

Searching this error reveals that there might be a network error.

ORA-16664: unable to receive the result from a database
Cause: During execution of a command, a database in the Data Guard broker configuration failed to return a result.
Action: Check Data Guard broker logs for the details of the failure. Fix any possible network problems and try the command again.

As the RMAN duplicatie is done over TNS using the following command
“rman target sys/xxx@prod AUXILIARY sys/xxx@stby” . I would say that the network setting for TNS are
correct, so what does this error actually mean ?

In the background i could find serveral Dataguard logfiles showing me mixed errors on the subject.

Primary site DG log shows :

….
DG 2009-05-19-08:48:27 1012000 4 686031872 DMON: CTL_GET_STATUS operation completed
DG 2009-05-19-08:48:45 0 2 0 NSV1: Received error ORA-16664 from target remote site stby.
DG 2009-05-19-08:48:45 0 2 686031873 DMON: Database stby returned ORA-16664
…

Standby site DG log shows :

…
DG 2009-05-19-08:51:00 0 2 686031879 Operation CTL_GET_STATUS continuing with warning, status = ORA-16809
DG 2009-05-19-08:51:00 0 2 0 NSV0: Failed to connect to remote database prod. Error is ORA-00604
DG 2009-05-19-08:51:00 0 2 0 NSV0: Failed to send message to site prod.
Error code is ORA-00604.
DG 2009-05-19-08:51:00 0 2 0 DMON: Database prod returned ORA-00604
…

The Data Guard Command-Line Interface ( DGMGRL ) showed the following error.

DGMGRL> show configuration

Configuration
Name: prod
Enabled: YES
Protection Mode: MaxPerformance
Databases:
prod – Primary database
stby – Physical standby database

Fast-Start Failover: DISABLED

Current status for “prod”:
Warning: ORA-16607: one or more databases have failed

All these errors seem very surfear but at the end it all came down to a faulty “logon trigger” which was implemented by another Database Administrator.
As normal connections worked this was not the first thing you would come to , but at the end by dropping this faulty trigger the problem was solved !

Remove configured backup jobs from command line on a 11g database repository.

When switching to a Grid monitoring environment, standalone dbconsole need to be shutdown and cleared out. Jobs scheduled using the dbconsole on a 11g instance cannot be retreived threw Oracle Enterprise Grid Console.
When your dbconsole is broke and you don’t want to have any jobs running which where submitted through the gui. Here is a way to delete them from you repository manually.


select JOB_OWNER, JOB_NAME from SYSMAN.MGMT_JOB;

SYSMAN ALLOWED FAILED LOGIN ATTEMPTS (CLUSTER DATABASE)
SYSMAN ALLOWED FAILED LOGIN ATTEMPTS (DATABASE INSTANCE)
SYSMAN FIX INVENTORY                                                
BCK XXX_BACKUP_FULL                                                 
BCK XXX_BACKUP_INCR                                            
BCK XXX_EXPORT_FULL                                                              
SYSMAN PROVISIONING DAEMON                                  
SYSMAN REFRESH_FROM_METALINK_JOB                              

For each job that you want to remove , run the following statement.


begin
sysman.mgmt_jobs.stop_all_executions('XXX_BACKUP_FULL','BCK');
sysman.mgmt_jobs.delete_job('XXX_BACKUP_FULL','BCK');
end;
/
commit;


Grant ACL permission for UTL_SMTP to be used in 11g database

After some searching it was clear that you need to create an Access Control List to provide access from within the database to allow connects to be made.
Despite of some information i found on this topic , the only thing i needed to provide this access to the MAILUSER was to execute these command as the sys user.


EXECUTE DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('acl_for_mail.xml', 'ACL for Mail Job','MAILUSER', TRUE, 'connect');
EXECUTE DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('acl_for_mail.xml','localhost', 25);
COMMIT;


You might want to grant this UTL_SMTP to the MAILUSER ,

grant execute on UTL_SMTP to MAILUSER;

Grant succeeded.

To add another user to the same ACL xml made earlier, you can use :

EXECUTE DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE('acl_for_mail.xml','MAILUSER2', TRUE, 'connect');
COMMIT;

If you are interesseted in seeing what network access is granted on acl_for_mail.xml, you can query this by executing this

SELECT host, lower_port, upper_port, acl
FROM dba_network_acls


Exception in thread “main” java.lang.InternalError: Can’t connect to X11 window

When running you runInstaller under another user then the current user logged into the X server screen, you might hit this error.
I ran into this error while being logged on to a vnc session running under the root user. While perfoming tasks under root , switched user to oracle and set the display back to the current screen

su – oracle
export DISPLAY=xxx:1

The installer starts but exits with the following error;

Starting Oracle Universal Installer…

….

Exception in thread “main” java.lang.InternalError: Can’t connect to X11 window
server using ‘xxx:1′ as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Unknown Source)
at java.awt.Window.init(Unknown Source)
at java.awt.Window.(Unknown Source)
at java.awt.Frame.(Unknown Source)
at java.awt.Frame.(Unknown Source)
at oracle.ewt.popup.PopupFrame.(Unknown Source)
at oracle.ewt.lwAWT.BufferedFrame.(Unknown Source)
at oracle.sysman.emgc.oneclick.OneClickWizard.getGuiDefaults(OneClickWizard.java:239)
at oracle.sysman.emgc.oneclick.OneClickWizard.(OneClickWizard.java:205)
at oracle.sysman.emgc.oneclick.OneClick.(OneClick.java:236)
at oracle.sysman.emgc.oneclick.OneClickInstaller.(OneClickInstaller.java:116)
at oracle.sysman.emgc.oneclick.OneClickInstaller.process(OneClickInstaller.java:268)
at oracle.sysman.emgc.oneclick.OneStartup.startup(OneStartup.java:383)
at oracle.sysman.emgc.oneclick.OneArgs.main(OneArgs.java:700)
at oracle.sysman.emgc.oneclick.OneStartup.main(OneStartup.java:391)
oracle@xxx:/u00/agent/linux/agent> ./runInstaller

A solution could be to disable access control under the user from which VNC is running , in my case under root.

xxx:/ # xhost +
access control disabled, clients can connect from any host
xxx:/ #

Now the runInstaller will start fine in this setup !

Easy Listener configuration

Here is my default database listener setup which has proven to be working just fine !
Offcourse you could also setup your listener as default and let the database register itself at the listener.

When you like to force this registration of database information you could use this command to force the register ;
SQL> alter system register;

Else you could control this yourself and manually add the database to the listener.ora like this :

Here is the content of my LISTERNER.ora

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u00/oracle/product/11.1.0/db)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = P001)
      (ORACLE_HOME = /u00/oracle/product/11.1.0/db)
      (SID_NAME = P001)
    )
  ) 

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = db.example.com)(PORT = 1521))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
    )
  ) 

LOG_DIRECTORY_LISTENER = /u00/oracle/network/log
LOG_FILE_LISTENER = LISTENER.log

Content of my SQLNET.ora

NAMES.DIRECTORY_PATH= (TNSNAMES)
NAMES.DEFAULT_DOMAIN = example.com 

## TRACING
# TRACE_LEVEL_SERVER=16
# TRACE_DIRECTORY_SERVER=/u00/oracle/network/trace
# TRACE_FILE_SERVER=server_db
# TRACE_TIMESTAMP_SERVER=ON

Content of my TNSNAMES.ora

P001.example.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = db.example.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = P001.example.com)
    )
  )