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>

Cleanup OID using ldapsearch and ldapdelete

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

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

Export/Import OID users using DSML xml standard

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
..

error while loading shared libraries: libaio.so.1: cannot open shared object file

While wanting to preform a disaster recovery using RMAN on a spare server which has an ORACLE_HOME 10.2.0.1 64bits installed on a Red Hat Enterprise Linux AS release 4 Operating System.
I tried the following to read back my controlfile. But before getting to this point i faced this error :

oracle@xxx: $ $ORACLE_HOME/bin/rman target /

Recovery Manager: Release 10.2.0.1.0 – Production on Wed Jul 8 10:32:56 2009

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

oraclewiki: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database:
ORA-12547: TNS:lost contact

Assuming the libaio library was installed i searched and tried to clear this up. As the server is a x86_64 server there should be a 64 bit library of libaio installed :

oracle@xxx: # find / -name libaio.so.1
/local/app/oracle/product/db10g/lib/stubs/libaio.so.1
/local/app/oracle/product/agent10g/lib/stubs/libaio.so.1
/local/app/oracle/product/db10gtest/lib/stubs/libaio.so.1
/local/app/oracle/product/10.2.0/db/lib/stubs/libaio.so.1
/local/app/oracle/product/10.2.0/db/lib32/stubs/libaio.so.1
/usr/lib/libaio.so.1

oracle@xxx: $ ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => not found

As i could see here, this was not the case. Only the 32 bit is availible and therefor not used by the Oracle 64 bits Database software.
The output of the ldd command supports this as there is a dependency problem for the oracle process on libaio.so.1.

After adding the following rpm’s i was able to connect without problems.

root@xxx: # up2date –showall | grep libaio | grep 64
libaio-0.3.105-2.x86_64
libaio-devel-0.3.105-2.x86_64

As you can see now the correct library is found and the dependency problem is solved.

oracle@xxx: $ ldd $ORACLE_HOME/bin/oracle | grep libaio
libaio.so.1 => /usr/lib64/libaio.so.1 (0×0000002a96f40000)

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>

Problems with the BACKSPACE key on Solaris or AIX

Every ran into the problem that the BACKSPACE key does not work ?
Instead you will get “^?” or “^h” on the screen when BACKSPACE is used.
^? will be returned on ksh shell and ^h will be returned when using a bash shell

When you want to lose this behaviour in your session you could execute the following command :

stty erase [BACKSPACE]

After this the BACKSPACE works again ! After logout the setting is gone and should be executed again.

Use ssh-keygen to setup password-less SSH login

Just a quick reminder on how to setup a simple password-less SSH login on your servers.
You might get lost in all documentation that is published on the topic. Here is what i execute to make it work !

Actions for the source server :

oracle@db $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/oracle/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): [LEAVE EMPTY]
Enter same passphrase again: [LEAVE EMPTY]
Your identification has been saved in /home/oracle/.ssh/id_rsa.
Your public key has been saved in /home/oracle/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx oracle@db.example.nl
oracle@db $

Resulting in ;

oracle@db $ ll
total 12
-rw——- 1 oracle oinstall 1675 Jul 3 11:33 id_rsa
-rw-r–r– 1 oracle oinstall 401 Jul 3 11:33 id_rsa.pub
-rw-r–r– 1 oracle oinstall 1138 Jul 3 10:38 known_hosts
oracle@db $

Actions for the remote server :

Now copy the content of the id_rsa.pub file in the authorized_keys on the server( db2 in my case ) you want to connect to. The location of the the file is /home/oracle/.ssh/authorized_keys

That it !

Now we can connect without the use of a password ;

oracle@db $ ssh db2
Last login: Fri Jul 3 11:37:41 2009 from db2.example.nl
oracle@db2$

I use this setup to be able to execute os command’s from within my script on a remote server.

java.security.cert.CertificateException: java.io.EOFException

tomcat@xxx $ keytool -import -trustcacerts -file cert_xxxx.pem -alias login.example.nl  -keystore ssl.keystore
Enter keystore password:  xxx
keytool error: java.security.cert.CertificateException: java.io.EOFException

After opening the pem file we saw a strange “enter” after the END CERTIFICATE.

—–END CERTIFICATE—–

~

After removing this obsolete “enter” line the import went well.

—–END CERTIFICATE—–
~

How to renew a Certificate in Oracle Wallet Manager

Open your Wallet Manager from your commandline using $ORACLE_HOME/bin/owm ( set your DISPLAY to the correct value )

Once started open your ewallet.p12 file which most likely can be found at the default location :

/etc/ORACLE/WALLETS/oracle

Enter your Wallet Password.

Select the Certificate which will expire.

Go to Operations -> Export Certificate Request.

Save this file to server in the default location

Send the Certificate request to your CA Authority.
When a new certificate is recieved continue by removing the existing user certificate ;

Select the Certificate which will expire and select OPERATIONS -> REMOVE USER CERTIFICATE

Confirm this with “Yes”

As showed below , your initail request is turning up again and is ready to receive a new certificate.

Select Operations – > Import User Certificate

Select your location

Now the result is again an up to date certificate in the Oracle Wallet.

Remember , for the certificatie to take effect it is required to restart Oracle depending services like Portal !