Exception in thread “main” java.lang.IndexOutOfBoundsException: No group 9

While installing Oracle Webcenter Suite 10.1.3.2.0 i ran into the following error.

Command: /u00/oracle/product/10.1.3/web/jdk/bin/java -jar /u00/oracle/product/10.1.3/web/j2ee/home/admin_client.jar deployer:oc4j:opmn://xxx.helvoort.nl:6004/OC4J_WebCenter oc4jadmin -script /u00/oracle/product/10.1.3/web/portal/conf/oc4jportal_server_xml.params
Exception in thread “main” java.lang.IndexOutOfBoundsException: No group 9
at java.util.regex.Matcher.group(Matcher.java:463)
at java.util.regex.Matcher.appendReplacement(Matcher.java:730)
at java.util.regex.Matcher.replaceAll(Matcher.java:806)
at java.lang.String.replaceAll(String.java:2000)
at oracle.webdb.config.PortletContainerConfigAssistant.replacePwd(Unknown Source)
at oracle.webdb.config.PortletContainerConfigAssistant.configServerXML(Unknown Source)
at oracle.webdb.config.PortletContainerConfigAssistant.main(Unknown Source)

Please use a password without “$” as this is not escaped during configuration and therefor causing the installation to fail during a replace action.

When trying to install an application server 10.1.3.2.0 i ran into the following error.

The error is thrown based on an earlier attempt on installing an application server. However, the product was removed successfully and should therefor not throw this error. Even when a different ORACLE_HOME is chosen , the error returns.
This behavior is caused by a corrupted Oracle Inventory as a quick peek in the file inventory.xml located in the ContentXML directory under your current oraInventory reveals that there is no such ORACLE_HOME present at this time.

As a workaround i created a dummy file called “oraInst.loc” in the “/tmp” directory containing these lines :

inventory_loc=/tmp/oraInventory
inst_group=dba

After creating this file , start your installer using

./runInstaller -invPtrloc /tmp/oraInst.loc

Your installer will continue now.

After switching our Embedded Gateway to an Apache front-end using modplsql.
We are faced with an error while loading interactive reports using FlashChart.

As we are using a Reverse Proxy to route the traffic to our internal servers , this is actually the cause of our problem for interactive report to show successfully.

In order to overcome this behavior , we added the following lines to our $ORACLE_APACHE_HOME/ohs/modplsql/dads.conf file in between the “Location” definition:

PlsqlCGIEnvironmentList HTTP_HOST=xxx.yenlo.nl

PlsqlCGIEnvironmentList REQUEST_PROTOCOL=http

xxx.yenlo.nl being our public adres for outside and “http” being our protocol.

Restart your apache services by executing :

[apache] xxx:bin> ./opmnctl stopall
opmnctl: stopping opmn and all managed processes…
[apache] xxx:bin> ./opmnctl startall
opmnctl: starting opmn and all managed processes…

Now your FlashChart should show up successfull again !

By default the Apache 2.0 version of Oracle HTTP Server is installed without using the HTTP “worker” method. As this is a performance enhancer , you would like to change your Apache configuration to implement the use of it.
For example , your Apex application will benefit from this as the multi-threated method with mod_plsql is supporting data connection pooling. The old fashion prefork method however is not and there for is not preferable.

Default your Apache process list will look like this after installing the Oracle HTTP Server (Apache 2.0) (10.1.3.3.0);

[apache] xxx:conf> ps -ef | grep httpd
oracle 3775 3738 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 3779 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 3781 3775 0 Oct31 ? 00:03:48 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 3794 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 3801 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 4042 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 4050 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 4327 3775 0 Oct31 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 16187 3775 0 Nov02 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 18433 3775 0 Nov01 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 22394 3775 0 Nov01 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 30316 3775 0 Nov02 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 30439 3775 0 Nov02 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd -d /u00/oracle/product/10.1.3/apache/ohs -DSSL

Here you can clearly see there is no worker process active, but instead the old fashion prefork processes are used.

The following can be done to implement the worker method which will add multi-threading to your httpd configuration.

open your opmn.xml ( located : $ORACLE_HOME/opmn/conf ) and find the following section :

    <ias-component id="HTTP_Server">
        <process-type id="HTTP_Server" module-id="OHS2">
          <module-data>
            <category id="start-parameters">
              <data id="start-mode" value="ssl-enabled"/>
            </category>
          </module-data>
          <process-set id="HTTP_Server" numprocs="1"/>
        </process-type>
      </ias-component>

Change it to ;

    <ias-component id="HTTP_Server">
        <process-type id="HTTP_Server" module-id="OHS2">
          <module-data>
            <category id="start-parameters">
              <data id="start-mode" value="ssl-enabled"/>
              <data id="mpm" value="worker"/>
            </category>
          </module-data>
          <process-set id="HTTP_Server" numprocs="1"/>
        </process-type>
      </ias-component>

After this just restart your opmn services

[apache] xxx:bin> ./opmnctl stopall
opmnctl: stopping opmn and all managed processes…
[apache] xxx:bin> ./opmnctl startall
opmnctl: starting opmn and all managed processes…

Now lets check if the worker method is implemented correctly;

[apache] xxx:bin> ps -ef | grep httpd
oracle 23556 23521 3 14:26 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd.worker -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 23560 23556 0 14:26 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd.worker -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 23562 23556 0 14:26 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd.worker -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 23564 23556 0 14:26 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd.worker -d /u00/oracle/product/10.1.3/apache/ohs -DSSL
oracle 23565 23556 0 14:26 ? 00:00:00 /u00/oracle/product/10.1.3/apache/ohs/bin/httpd.worker -d /u00/oracle/product/10.1.3/apache/ohs -DSSL

When you are getting back the httpd.worker process you are running the multithreaded (MPM) method of the Apache 2.0 HTTP Server.

While installing the latest HTTP Server (Oracle HTTP Server (Apache 2.0) (10.1.3.3.0) ) from oracle to take advantage of the modplsql module that is provided.
The installation completed succesfully but still the httpd process could not start because of missing library dependencies.

When opening your $ORACLE_ACACHE_HOME/opmn/logs/HTTP_Server~1.log

you could find the following errors there :

——–
09/10/31 18:28:32 Start process
——–

/u00/oracle/product/10.1.3/apache/ohs/bin/apachectl startssl: execing httpd
/u00/oracle/product/10.1.3/apache/ohs/bin/httpd: error while loading shared libraries: libgdbm.so.2: cannot open shared object file: No such file or directory

——–
09/10/31 18:37:31 Start process
——–
/u00/oracle/product/10.1.3/apache/ohs/bin/apachectl startssl: execing httpd
/u00/oracle/product/10.1.3/apache/ohs/bin/httpd: error while loading shared libraries: libdb-3.3.so: cannot open shared object file: No such file or directory

In the same order you could fix this by creating symbolic links to the current shared library for each missing library.

( execute as root user )
cd /usr/lib

ln -s libgdbm.so.3.0.0 libgdbm.so.2

ln -s libdb-4.3.so libdb-3.3.so

These versions are found on “SUSE Linux Enterprise Server 10 SP2 (i586)” , your symbolic links can be different when the problem is faced on a different version operating system.
Please adjust accordingly.

( execute as root user )
cd /usr/lib

ln -s libgdbm.so.X.0.0 libgdbm.so.2

ln -s libdb-4.X.so libdb-3.3.so

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)

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>

Today is was asked to cleanup an Oracle Internet Directory without removing the orcladmin and some other operational users.
As all accounts are housed under the same context root , being “cn=Users,dc=example,dc=com”. I was forced to use an ldapsearch instead of using bulkdelete to perform the operation.

First we exported all the users :

ldapsearch -h oid.example.com -p 389-L -D “cn=orcladmin” -w “xxx” -b “cn=Users,dc=example,dc=com” -s sub “objectclass=*” > users_oid.ldif

After this a ldif is created with all user and attributes which cannot be used directly by ldapdelete.

Second we filter out only the “dn:” lines :

cat users_oid.ldif | grep dn: > users_delete.ldif

Then we remove the lines

dn: cn=Users, dc=example,dc=com
dn: cn=orcladmin, cn=Users, dc=example,dc=com
…
..

After this we remove the “dn:” from all lines as this would result in an error when kept.

sed s/dn:// users_delete.ldif > new_users_delete.ldif

Now we have created a clean ldif file which can be used by ldapdelete !

ldapdelete -h oid.example.com -p 389 -D “cn=orcladmin” -w xxx -f new_users_delete.ldif

Depending on the number of users in your ldap directory, this could take a while :)

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 :)

When using the DSML (Directory Service Markup Language) standard we create a representation of directory service information in an XML syntax instead of a ldif syntax.

ldapsearch -h source.example.com -p 389 -X -D “cn=orcladmin” -w “xxx” -b “cn=Users,dc=example,dc=com” -s sub “objectclass=*” > /home/oracle/source_users.xml

To prevent this error when importing ;

adding new entry cn=james, cn=Users, dc=example, dc=com
ldap_add: DSA is unwilling to perform
ldap_add: additional info: You cannot add entries containing authpasswords.

We need to process our source_users.xml to not hold this attribute. To accomplish this we used a xsl template created by mgueury.

del_auth_password.xsl

<!--
  File    : del_authpassword.xsl
  Version : 1.0
  Author  : mgueury
  Description:
    Remove the authpassword from the DSML files
-->
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xml:output method="xml"/>

  <xsl:template match="*|@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="*|@*|node()"/>
    </xsl:copy>
  </xsl:template>

  <xsl:template match="attr">
    <xsl:choose>
      <xsl:when test="@name='authpassword;oid'">
      </xsl:when>
      <xsl:when test="@name='authpassword;orclcommonpwd'">
      </xsl:when>
      <xsl:otherwise>
        <xsl:copy>
          <xsl:apply-templates select="*|@*|node()"/>
        </xsl:copy>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

</xsl:stylesheet>

To use this we executed the following command ;

xml -f -s /home/oracle/del_auth_password.xsl -o /home/oracle/target_users.xml /home/oracle/source_users.xml

After this we can fill our target OID with the clean target_users.xml;

ldapadd -h target.example.com -p 389 -D “cn=orcladmin” -w “xxx” -c -X /home/oracle/target_users.xml

adding new entry cn=james, cn=Users, dc=example, dc=com
adding new entry cn=jake, cn=Users, dc=example, dc=com
adding new entry cn=marly, cn=Users, dc=example, dc=com
adding new entry cn=john, cn=Users, dc=example, dc=com
..