Sunday, May 19, 2013

Rman catalog creation in 11gr2 database

RMAN CATALOG CREATION IN 11GR2 DATABASE

The catalog database acts as the centralized inventory of  database's and stores the backup details of all the database which is registered with it .. there are two methods the Rman can be operated the control file and the Recovery catalog
For creating the recovery catalog database we need to create the new database or we can use the existing database .. But the safe parctice is to create the new database which is dedicated for the CATALOG ..
The benefit of using the recover catalog is all the backup information of the database is stored in recover catalog database tables and we can query the status of the backup and the details of the backup from the recovery catalog database

Step 1
Create the Separate database which is going to host the Rman catalog database

Step 2
Create the Separate  table space which will hold all the catalog schema tables in it 
SQL> CREATE TABLESPACE <tables pace_name>
  2  DATAFILE '<datafile_name>' size 10240M
  3  Autoextend on;
Tablespace created.


Step3 

Create the new user which will the Owner of the Rman catalog
Create user <username> identified by <password>
Default tablespace <tablespace_name>
Temporary tablespace <temporary tablespace name>
Quota <percentage of allocated quota> on <table space>


 Step 4
Grant the recovery catalog owner role to the rcat user


Step5
Fom the O/S Prompt connect to the rman


Step 6 
Connect to the recover catalog by using the new user name which we have created 

Step 7
Connect to the recover catalog and register the database










Tuesday, May 14, 2013

RMAN-20020: database incarnation not set

RMAN-06004: ORACLE error from recovery catalog database: RMAN-20020: database incarnation not set

When we try to back the resync the catalog with the target database if we get this message then we have to reset the database to set the incarnation to the current
it can be cauased when we open the database with reset logs or if the  upgrade the catalog and connect with the target database
The database incarnations are used to identify the database backup belongs to which period .. for ex. day 1 when we take the back of the database then a incarnation will be generated and stored .. if we restore the database and the open it again then the new incarnation number will be generated .. now if we want to restore the backup which is take on the day one then we must set the database incarnation to the first incarnation number by using the RESET DATABASE TO INCARNATION                        the database control file will also hold the incarnation number in it

Step 1
connect to  rman and connect to the target database with recovery catalog
[ora@fa ~]$ rman
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 14 13:35:00 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
RMAN> connect target /
connected to target database: <SID> (DBID=<database_id>)
 
RMAN> connect catalog rcat/<password>@<catalog database service name>
connected to recovery catalog database

Step2

RMAN> resync catalog
2> ;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync command on default channel at 05/14/2013 13:36:02
RMAN-20020: database incarnation not set

RMAN> backup datafile <file_number>;
Starting backup at 14-MAY-13
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 05/14/2013 13:37:14
RMAN-03014: implicit resync of recovery catalog failed
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20020: database incarnation not set

Step 3
once you got the incarnation not set check the list of incarnation the database has

RMAN> list incarnation ;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
29      360     FAHDB    728861041        PARENT  1          05-MAR-12
29      361     FAHDB    728861041        PARENT  14640435   08-JUN-12
29      98      FAHDB    728861041        PARENT  14882874888 22-JUN-12
29      30      FAHDB    728861041        ORPHAN  15574861795 11-JUL-12
29      321     FAHDB    728861041        CURRENT 15996977185 22-AUG-12
1       17      ORACAT   2821584587       PARENT  1          05-SEP-10
1       2       ORACAT   2821584587       CURRENT 972274     12-MAY-13

SQL> select * from v$controlfile_record_section where TYPE ='DATABASE INCARNATION';

TYPE                         RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
---------------------------- ----------- ------------- ------------ ----------- ---------- ----------
DATABASE INCARNATION                  56           292            4           1          4          4

we can check the no of database incarnations in the database control file ...

Step 4
To sync the incarnation number with the catalog issue the Reset the database  command in the rman 
and test the backup

RMAN> reset database;

database incarnation already registered

RMAN> backup datafile 3;
Starting backup at 14-MAY-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4256 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00003 name=+DATA/fahdb/datafile/<datafile_number>
channel ORA_DISK_1: starting piece 1 at 14-MAY-13
channel ORA_DISK_1: finished piece 1 at 14-MAY-13
piece handle=+FLASH/fahdb/backupset/2013_05_14/nnndf0_tag20130514t135843_0.282.815407125 tag=TAG20130514T135843 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 14-MAY-13
Starting Control File and SPFILE Autobackup at 14-MAY-13
piece handle=+FLASH/fahdb/autobackup/2013_05_14/s_815407132.326.815407133 comment=NONE
Finished Control File and SPFILE Autobackup at 14-MAY-13

RMAN> resync catalog ;
starting full resync of recovery catalog
full resync complete






Monday, May 13, 2013

PL/SQL package RCAT.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not current

PL/SQL package RCAT.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not current

when we are trying to connect the Rman catalog database we are getting  the error it is cause because The particular version of the source database catalog is not sync with the current catalog..
The Cause of this Error is due to the recover catalog database or the target database must be upgraded .. or the recover catalog database is changed

Step 1

[ora@fah ~]$ rman

Recovery Manager: Release 11.2.0.3.0 - Production on Mon May 13 17:18:58 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
RMAN> connect target /
connected to target database: <SID> (DBID=<>)

RMAN> connect catalog rcat/<password>@ORACAT<Domain_name>
connected to recovery catalog database
PL/SQL package RCAT.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not current
PL/SQL package RCAT.DBMS_RCVMAN version 11.02.00.02 in RCVCAT database is not current

Step 2

For check the issue if we give the Register database or Resync catalog thou will get the below error message

RMAN> register database;

DBGSQL:     RCVCAT> begin dbms_rcvman.dumpPkgState('RCVMAN after sqlerror'); end;
DBGSQL:        sqlcode = 6550
DBGSQL:     RCVCAT> begin dbms_rcvcat.dumpPkgState('RCVCAT after sqlerror');end;
DBGSQL:        sqlcode = 6550
database registered in recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03008: error while performing automatic resync of recovery catalog
RMAN-10015: error compiling PL/SQL program
RMAN-10014: PL/SQL error 0 on line 1655 column 12: Statement ignored
RMAN-10014: PL/SQL error 306 on line 1655 column 12: wrong number or types of arguments in call to 'CHECKTABLESPACE'

RMAN> resync catalog;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync command on default channel at 05/13/2013 17:19:38
RMAN-10015: error compiling PL/SQL program
RMAN-10014: PL/SQL error 0 on line 1655 column 12: Statement ignored
RMAN-10014: PL/SQL error 306 on line 1655 column 12: wrong number or types of arguments in call to 'CHECKTABLESPACE'

Step 3

We need to give the upgrade catalog command to sync the new change in the binaries to reflect in the catalog database

RMAN> upgrade catalog;

recovery catalog owner is RCAT
enter UPGRADE CATALOG command again to confirm catalog upgrade

RMAN> upgrade catalog;

recovery catalog upgraded to version 11.02.00.03
DBMS_RCVMAN package upgraded to version 11.02.00.03
DBMS_RCVCAT package upgraded to version 11.02.00.03



Step 4
Connect the target database with the rman and catalog now you can issue the command report schema

[oratest@fahtestapp ~]$ rman

Recovery Manager: Release 11.2.0.3.0 - Production on Mon May 13 17:21:20 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
RMAN> connect target /
connected to target database: <SID> (DBID=<dbid_number>)
RMAN> connect catalog rcat/<password>@ORACAT.<Domain_name>
connected to recovery catalog database

RMAN> report schema;
Report of database schema for database with db_unique_name <SID>
List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
---
----
----
List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
---
---























Thursday, May 2, 2013

Purging In Fusion Applications for the ESS Job files


Purging Fusion Applications ESS job files 

We need to purge the ess job data in the regular intervals in the fusion applications all the ess jobs details will be store in the FUSION_TX_TOOLS table space.. if your are not purging the data in the regular time interval then there will be a huge the growth of the fusion tools  table space.. In fusion we can purge the data by Specifying the application and function and programs 

Step 1

Login to the fusion applications Enterprise Manger which is your  default Domain for example if you are Under the Financial Domain then Login to the Fin Em if you are in HCM then log in to the HCM Em 


 Step 2

Navigate to the Farm_<Default_Domain> -->Scheduling Services ->ESSAPP-->
and click the essserver under 


Step 3
Select the scheduling services under the ESSAPP server from the top left side and select the Purge Policies from the drop down menu 

Step 4
It will take to the new page and you can click the setup new button to setup new purge policy


Step 5
navigate to the Purge Policy Setup page

Provide the Name for the Purge Policy for example if u want to purge all your import journal related data then provide the naming convention with that 

Step 6

Select the Particular module which need to be purged 
 
Step 7

Select the applications which the particular program resides 
for ex: we need to purge the import journal's data then we need to select the  FinancialsESSApp

 

Step8
 Select the necessary program and which it details to be purged 


Step 9
Specify  the execution type  and summited by the user name  if needed
we need to specify the no of retention period which the data will remain in the system
for example if we specify the retention period as 120 then the last 120 days records will be available in the system  we need to specify the retention period level for all the parameters like success.. failure..


Step10

Click the scheduling process for scheduling it  and you can use the existing schedule also or click once to run now with the time specified

Step 11
One the purge policy was create you can see it will be in the wait state until the Specific time

Step 12

Once the job is completed you can see the details of the request by clicking the request number

 We can check the details from the ess server also 

After This process in the Em we need to manually purge the data from the database.all the ESS job related data are store under the schema FUSION_ORA_ESS check the tables to know the details of the ESS jobs..

TABLE_NAME                               OWNER                          TABLESPACE_NAME
---------------------------------------- ------------------------------ ------------------------------
SCHEMA_INFO                              FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_CONFIG                               FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_APP_CONFIGS                          FUSION_ORA_ESS                 FUSION_TS_TOOLS
JOB_INCOMPATIBILITY                      FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_APP_REGISTRATION                     FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_COORD                                FUSION_ORA_ESS                 FUSION_TS_TOOLS
OPERATIVE_BINDINGS                       FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_HISTORY                          FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_PROPERTY                         FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_CONSTRAINT                       FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_CP                               FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_METADATA                         FUSION_ORA_ESS                 FUSION_TS_TOOLS
WAIT_QUEUE                               FUSION_ORA_ESS                 FUSION_TS_TOOLS
WORK_UNITS                               FUSION_ORA_ESS                 FUSION_TS_TOOLS
EVENT_WORK                               FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_INCOMPATIBILITY                  FUSION_ORA_ESS                 FUSION_TS_TOOLS
INCOMPATIBILITY_LOCK                     FUSION_ORA_ESS                 FUSION_TS_TOOLS
COMMAND_WORK                             FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_ATTRIBUTE                        FUSION_ORA_ESS                 FUSION_TS_TOOLS
REQUEST_CONTENT                          FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_TEMP_REQID                           FUSION_ORA_ESS
PTEMP_REQUEST                            FUSION_ORA_ESS                 FUSION_TS_TOOLS
RECOVERY_DELETE                          FUSION_ORA_ESS                 FUSION_TS_TOOLS
FAILED_EXECUTION_HISTORY                 FUSION_ORA_ESS                 FUSION_TS_TOOLS
SCRATCH_QUERY_PRINCIPAL                  FUSION_ORA_ESS                 FUSION_TS_TOOLS
ESS_WS_ASYNC_INFO                        FUSION_ORA_ESS                 FUSION_TS_TOOLS
UNTHROTTLED_WORKASSIGNMENTS              FUSION_ORA_ESS                 FUSION_TS_TOOLS
ASYNC_ALLOCATIONS                        FUSION_ORA_ESS                 FUSION_TS_TOOLS
ASYNC_LIMITS                             FUSION_ORA_ESS                 FUSION_TS_TOOLS
CONFIGURED_BINDINGS                      FUSION_ORA_ESS                 FUSION_TS_TOOLS
EVENT_FILTER                             FUSION_ORA_ESS                 FUSION_TS_TOOLS

31 rows selected.
These are the number of tables count from each schema form the fusion which is occupied in the fusion_ts_tools table space
 
SQL> select distinct(owner),count(table_name)"no_of_tables" from dba_tables where tablespace_name ='FUSION_TS_TOOLS'
  2   group by owner
  3  order by 2;


OWNER                                    no_of_tables
---------------------------------------- ------------
FUSION_ORASDPLS                                     1
FUSION                                                           1
FUSION_ORASDPXDMS                              5
FUSION_ORASDPSDS                                  7
FUSION_PORTLET                                       12
FIN_FUSION_MDS_SOA                             14
FUSION_MDS_ESS                                      14
CRM_FUSION_MDS_SOA                          14
FUSION_MDS_SPACES                               14
PRJ_FUSION_MDS_SOA                             14
OIC_FUSION_MDS_SOA                             14
FUSION_MDS                                                14
SETUP_FUSION_MDS_SOA                        14
HCM_FUSION_MDS_SOA                           14
SCM_FUSION_MDS_SOA                            14
PRC_FUSION_MDS_SOA                             14
FUSION_ORA_ESS                                       30
FUSION_ORASDPM                                     31
FUSION_ACTIVITIES                                  42
FUSION_OTBI                                               44
FUSION_IPM                                                 49
FUSION_WEBCENTER                                66
FUSION_DISCUSSIONS                               69
FUSION_OCSERVER11G                             119
FUSION_BIPLATFORM                               152
FUSION_ODI                                                183
CRM_FUSION_SOAINFRA                         265
FIN_FUSION_SOAINFRA                            265
SETUP_FUSION_SOAINFRA                      265
SCM_FUSION_SOAINFRA                          265
HCM_FUSION_SOAINFRA                         265
PRJ_FUSION_SOAINFRA                            265
PRC_FUSION_SOAINFRA                           265
OIC_FUSION_SOAINFRA                            265

Once you have complete the Purging policy in the EM .. and successfully completed it ..the next step is to delete the metadata from the database directly

connect the database as the Fusion_ora_ess and then run the package
esspurge.purge_requests
The parameter are  
systimestamp = which you can specify the date no of days to retention [in this example we have specified 120 and it will hold last 120 days records and purge remaining data ]
The no of request can be purged : you can specify the number according to your wish [in this example we have specified 1000000 as the max number of records to be purged]

SQL> connect FUSION_ORA_ESS
Enter password:
Connected.
SQL> set serveroutput on size unlimited
SQL> set timing on
SQL> execute esspurge.purge_requests(systimestamp - 120,1000000);

PL/SQL procedure successfully completed.

Elapsed: 00:01:03.88
SQL>

[opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed

[opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed


When we are trying to start the Opmn process it gives this kind of error for one process .. it is due to the states file which holds the process id of the particular process and it states.. if Any changes are done in the file while the process is up then the when we bring down and restart the opmn process it will hold the changed state which will reflect the wrong Change

Step 1

Start the opmn process
[orabi@ob]$ ./opmnctl startall
opmnctl startall: starting opmn and all managed processes...
================================================================================
opmn id=obitst.oasiserp.com:9501
Response: 4 of 5 processes started.

ias-instance id=instance1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ias-component/process-type/process-set:
  coreapplication_obips1/OracleBIPresentationServicesComponent/coreapplication_obips1/

Error
--> Process (index=1,uid=1374230127,pid=8063)
  failed to start a managed process after the maximum retry limit
  Log:
  <base_dir>/fmw/instances/instance1/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1/console~coreapplication_obips1~1.log

Step2
check the log files of the opmn to find the exact cause of the issue
[bi@ob opmn]$ pwd
<base_dir>/fmw/instances/instance1/diagnostics/logs/OPMN/opmn
[bi@ob opmn]$ ll
total 668
-rw-r----- 1 orabi oinstall  39960 May  1 17:25 logquery~1.log
-rw-r----- 1 orabi oinstall  39533 May  1 17:25 logquery~2.log
-rw-r----- 1 orabi oinstall  37385 May  1 17:25 logquery~3.log
-rw-r----- 1 orabi oinstall  37374 May  1 17:25 logquery~4.log
-rw-r----- 1 orabi oinstall  37925 May  1 17:25 logquery~5.log
-rw-r----- 1 orabi oinstall 467588 May  2 13:13 opmn.log
-rw-r----- 1 orabi oinstall   1632 May  2 13:12 opmn.out

Step 3
Open the opmn.log file and you will find the error messages like below .. the particular uid which is stored in the states folder will not be changed Science the new change is not acceptable 

[2013-05-02T13:13:00+04:00] [opmn] [ERROR:1] [] [libopmncustom] Ping failed in Ready callback for proc:1374230126
[2013-05-02T13:13:02+04:00] [opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed: coreapplication_obis1~OracleBIServerComponent~coreapplication_obis1~1 (1374230126:7905) [No addresses matched the properties for the request]
[2013-05-02T13:13:02+04:00] [opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed: coreapplication_obis1~OracleBIServerComponent~coreapplication_obis1~1 (1374230126:7905)
[2013-05-02T13:13:02+04:00] [opmn] [ERROR:1] [] [libopmncustom] Ping failed in Ready callback for proc:1374230126
[2013-05-02T13:13:04+04:00] [opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed: coreapplication_obis1~OracleBIServerComponent~coreapplication_obis1~1 (1374230126:7905) [No addresses matched the properties for the request]
[2013-05-02T13:13:04+04:00] [opmn] [ERROR:1] [] [libopmncustom] Process Ping Failed: coreapplication_obis1~OracleBIServerComponent~coreapplication_obis1~1 (1374230126:7905)
[2013-05-02T13:13:04+04:00] [opmn] [ERROR:1] [] [libopmncustom] Ping failed in Ready callback for proc:1374230126
[2013-05-02T13:13:06+04:00] [opmn] [NOTIFICATION:1] [665] [pm-process] Process Alive: coreapplication_obis1~OracleBIServerComponent~coreapplication_obis1~1 (1374230126:7905)
[2013-05-02T13:13:06+04:00] [opmn] [NOTIFICATION:1] [668] [pm-requests] Request 2 Completed. Command: /start
                         
Step 4
Navigate to the states file location and find the states file and rename the states file into the new one when the opmn start it will create the new states file which will hold the current details in it

[bi@ob opmn]$ pwd
<base_dir>/fmw/instances/instance1/config/OPMN/opmn
[bi@ob opmn]$ ls
instance.properties  instance.properties.bak  opmn.xml  ports.prop  states  states742013  states_orginal  wallet
[bi@ob opmn]$ cd states
[bi@ob states]$ ls
p1374230126  p1374230128  p1374230129  p1374230130
[orabi@obitst states]$ ll
total 16
-rw-r----- 1 orabi oinstall 487 May  2 13:13 p1374230126
-rw-r----- 1 orabi oinstall 264 May  2 13:12 p1374230128
-rw-r----- 1 orabi oinstall 508 May  2 13:12 p1374230129
-rw-r----- 1 orabi oinstall 240 May  2 13:12 p1374230130

Step5

If any one of the particular process in the opmn is not Coming up then check the log file for that Process to find the exact reason behind it

[bi@ob bin]$ ./opmnctl status -l
Processes in Instance: instance1
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
ias-component                    | process-type       |     pid | status   |        uid |  memused |    uptime | ports
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
coreapplication_obiccs1          | OracleBIClusterCo~ |   15448 | Alive    |  882845249 |   200772 |   0:02:07 | N/A
coreapplication_obisch1          | OracleBIScheduler~ |   15446 | Alive    |  882845248 |   403024 |   0:02:07 | N/A
coreapplication_obijh1           | OracleBIJavaHostC~ |   15447 | Alive    |  882845247 |  1465000 |   0:02:07 | javahost:9810
coreapplication_obips1           | OracleBIPresentat~ |     N/A | Down     |        N/A |      N/A |       N/A | N/A
coreapplication_obis1            | OracleBIServerCom~ |   15444 | Alive    |  882845245 |  1318908 |   0:02:07 | N/A
Try to start the particular process and check the log files and fix the issue

[bi@ob bin]$ ./opmnctl startproc ias-component=coreapplication_obips1
opmnctl startproc: starting opmn managed processes...
================================================================================
opmn id=obitst.oasiserp.com:9501
Response: 0 of 1 processes started.

ias-instance id=instance1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--------------------------------------------------------------------------------
ias-component/process-type/process-set:
  coreapplication_obips1/OracleBIPresentationServicesComponent/coreapplication_obips1/

Error
--> Process (index=1,uid=882845250,pid=15806)
  failed to start a managed process after the maximum retry limit
  Log:
  <base_dir>/fmw/instances/instance1/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1/console~coreapplication_obips1~1.log

Navigate to the particular log folder for that particular  service then check the log files for it
[orabi@obitst coreapplication_obips1]$ pwd
<base_dir>/fmw/instances/instance1/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1

[2013-05-02T13:32:35.000+04:00] [OBIPS] [ERROR:31] [] [saw.i18n.currencyLookup.loadCurrencies] [ecid: ] [tid: ] Sax parser returned an exception.
Message: An exception occurred! Type:UTFDataFormatException, Message:invalid byte 1 () of a 1-byte sequence., Entity publicId: <base_dir>/fmw/Oracle_BI1/bifoundation/web/display/currencies.xml, Entity systemId: , Line number: 1, Column number: 40[[
File:saxreader.cpp
Line:681
Location:
        saw.i18n.currencyLookup.loadCurrencies
        saw.webextensionbase.init
        saw.sawserver
currenciesFile: <base_dir>/fmw/Oracle_BI1/bifoundation/web/display/currencies.xml


Step 6
Once you remove the states folder and the fixed any other issue causing the failure then conform that no opmn process is currently running and start the opmnctl process
Navigate to the <base_dir>/fmw/instances/instance1/bin
[bi@ob bin]$ ./opmnctl status -l

Processes in Instance: instance1
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
ias-component                    | process-type       |     pid | status   |        uid |  memused |    uptime | ports
---------------------------------+--------------------+---------+----------+------------+----------+-----------+------
coreapplication_obiccs1          | OracleBIClusterCo~ |    9801 | Alive    |  882845234 |   201904 |   0:05:47 | N/A
coreapplication_obisch1          | OracleBIScheduler~ |    9799 | Alive    |  882845233 |   337500 |   0:05:47 | N/A
coreapplication_obijh1           | OracleBIJavaHostC~ |    9800 | Alive    |  882845232 |  1466316 |   0:05:47 | javahost:9810
coreapplication_obips1           | OracleBIPresentat~ |    9798 | Alive    |  882845231 |   491884 |   0:05:47 | N/A
coreapplication_obis1            | OracleBIServerCom~ |    9797 | Alive    |  882845230 |  1316932 |   0:05:47 | N/A