Monitoring user SYS will expire in -32,799 hours

 

ORA-04029: error ORA-7445

ORA-04029: error ORA-7445 occurred when querying Table/View

Solution:

alter system flush shared_pool

Switchover Oracle 10g from Primary to Standby

Validate Primary and standby for swichover.
Verify Managed Recovery is Running (non-broker) on the standby

SQL> SELECT PROCESS
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'MRP%';

Cancel apply delay for the target standby using SQL
On the target physical standby database capture the current delay value

SQL> SELECT DELAY_MINS
FROM V$MANAGED_STANDBY
WHERE PROCESS = 'MRP0';

On the target physical standby database turn off delay if > 0

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Ensure Online Redo Log Files on the Target Physical Standby have been cleared

On the target physical standby run the following query to determine if the online redo logs have not been cleared:

SQL> SELECT DISTINCT L.GROUP#
FROM V$LOG L, V$LOGFILE LF
WHERE L.GROUP# = LF.GROUP#
AND L.STATUS NOT IN (‘UNUSED’, ‘CLEARING’,’CLEARING_CURRENT’);

If the above query returns rows, on the target physical standby issue the following statement for each GROUP# returned:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

Check for Previously Disabled Redo Threads
To determine if this situation exists, on your primary database, first run the following query to determine if there are any threads with a SEQUENCE# greater than 0:

SQL> SELECT THREAD#
FROM V$THREAD
WHERE SEQUENCE# > 0;

On the primary database, determine the current database redo branch:

SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#)
FROM V$DATABASE_INCARNATION
WHERE STATUS = 'CURRENT';

Any of the threads identified by the first query are disabled provided there are no archive log or log history records in the control file of the target physical standby database on the current branch of redo on the primary.

To determine this, substitute the resetlogs_change# from the primary database (found in the second query) into the query below and execute it on the target physical standby database for each thread reported from the first query above.

SQL> SELECT 'CONDITION MET'
FROM SYS.DUAL
WHERE NOT EXISTS (SELECT 1
FROM V$ARCHIVED_LOG
WHERE THREAD# =
AND RESETLOGS_CHANGE# = )
AND NOT EXISTS (SELECT 1
FROM V$LOG_HISTORY
WHERE THREAD# =
AND RESETLOGS_CHANGE# = );

If this query returns a row for any of the threads, you have a disabled thread with a non-zero SEQUENCE# that can prevent a switchover from the primary database to the physical standby database. In this case, you must apply the latest patchset or use one of the following workarounds:

Check if the standby has ever been open read-only
On the target physical standby database run this query:

SQL> SELECT VALUE
FROM V$DATAGUARD_STATS
WHERE NAME='standby has been open';

Verify there are no large GAPS.
Identify the current sequence number for each thread on the primary database

SQL> SELECT THREAD#, SEQUENCE# FROM V$THREAD;

Verify the target physical standby database has applied up to, but not including the logs from the primary query. On the standby the following query should be no more than 1-2 less than the primary query result.

SQL> SELECT THREAD#, MAX(SEQUENCE#)
FROM V$ARCHIVED_LOG
WHERE APPLIED = 'YES'
AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION
WHERE STATUS = 'CURRENT')
GROUP BY THREAD#;

 Verify Primary and Standby TEMP Files Match
On the standby for each temporary tablespace, verify that temporary files associated with that tablespace on the primary database also exist on the standby database. Temp files added after initial standby creation are not propagated to the standby. Run this query on both the primary and target physical standby databases and verify that they match.

SQL> SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
FROM V$TEMPFILE TMP, V$TABLESPACE TS
WHERE TMP.TS#=TS.TS#;

If the queries do not match then you can correct the mismatch now or immediately after the open of the new primary.

To correct now: add or delete a tempfile now requires managed recovery to be stopped and the standby to be open read only. Opening the standby read-only will require a database close and open before becoming the new primary, see “Open the new primary database”.

To correct post-primary-open: see “Correct any tempfile mismatch” step of Switchover

Verify that there is no issue with V$LOG_HISTORY on the Standby

Determine threads that have been active at some point on the primary database:

SQL> SELECT THREAD#, SEQUENCE#
FROM V$THREAD
WHERE SEQUENCE# > 0;

Get the RESETLOGS_CHANGE# from the primary database:
SQL> SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION
WHERE STATUS = 'CURRENT';

On the target physical standby database, get the maximum sequence numbers for each thread from V$LOG_HISTORY:
SQL> SELECT THREAD#, MAX(SEQUENCE#)
FROM V$LOG_HISTORY
WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
GROUP BY THREAD#;

The last SEQUENCE# for each THREAD# from V$LOG_HISTORY on the target physical standby database should be close (the difference in log sequences < 3) to the SEQUENCE# for each THREAD# from V$THREAD on the primary database. If the difference in log sequences is greater than 3 or no row is returned for the thread, you have encountered this problem and should recreate the standby controlfile. See Note 459411.1. If backups are being done on the standby without an RMAN Catalog then backup history will be lost. It is highly recommended to use an RMAN Catalog for all backups.

Verify no old partial Standby Redo Logs on the Standby

Get the RESETLOGS_CHANGE# from the primary database:
SQL> SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION
WHERE STATUS = 'CURRENT';

On the target physical standby database, identify any active standby redo logs (SRL’s)
SQL> SELECT GROUP#, THREAD#, SEQUENCE#
FROM V$STANDBY_LOG
WHERE STATUS = 'ACTIVE'
ORDER BY THREAD#,SEQUENCE#;

On the target physical standby database, identify maximum applied sequence number(s).
SQL> SELECT THREAD#, MAX(SEQUENCE#)
FROM V$LOG_HISTORY
WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
GROUP BY THREAD#;

If there are any active SRL's that have a thread#/sequence# less than the thread#/sequence# returned from the V$LOG_HISTORY (meaning the recovery has progressed beyond the active SRL) query, clear them on the target physical standby.

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

Swichover to DR.
Clear Potential Blocking Parameters & Jobs

Capture current job state on the primary

SQL> SELECT *
FROM DBA_JOBS_RUNNING; [depending on what the running job is, be ready to terminate]

SQL> SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED
FROM DBA_SCHEDULER_JOBS
WHERE ENABLED='TRUE'
AND OWNER <> 'SYS';

SQL> SHOW PARAMETER job_queue_processes

Note: cron job candidates to be disabled among others: oracle text sync and optimizer, RMAN backups, application garbage collectors, application background agents.

Block further job submission

SQL> ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID='*';

SQL> EXECUTE DBMS_SCHEDULER.DISABLE( );

Disable any cron jobs that may interfere.

Create Guaranteed Restore Points

Create a guaranteed restore point on the primary
Verify if flashback database is on or a guaranteed restore point already exists

SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

NOTE: Unless you have a backport for Bug 7568556, “ACTIVE APPLY RATE SEEN FROM 63MB/S TO 544KB/S AFTER RESTORE POINT ENABLED”, you should not have just a guaranteed restore point only (V$DATABASE.FLASHBACK_ON=”RESTORE POINT ONLY”) and ensure that flashback database is also on (V$DATABASE.FLASHBACK_ON=”YES”) when creating a guaranteed restore point.

If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires the database to be mounted.

See Enabling Logging for Flashback Database for those steps.

Create the guaranteed restore point

SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;
Create a guaranteed restore point on the standby
Verify if flashback database is on or a guaranteed restore point already exists

SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires being in the MOUNT state.

See Enabling Logging for Flashback Database for those steps.

Create the guaranteed restore point

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Verify that the primary database can be switched to the standby role

Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database. For example:
SQL> SELECT SWITCHOVER_STATUS
FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO STANDBY

A value of TO STANDBY or SESSIONS ACTIVE (requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role. If neither of these values is returned, a switchover is not possible because redo transport is either mis-configured or is not functioning properly

Switchover the primary to a standby database

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

If an ORA-16139 is encountered, as long as V$DATABASE.DATABASE_ROLE=’PHYSICAL STANDBY’, then you can proceed. A common case where this can occur is when there are a large number of data files, greater than 1,000, the apply of the EOR log will timeout.. Once managed recovery is started on the new standby it will recover.

If the role was not changed then you need to cancel the switchover and review the alert logs and trace files further.

Verify the standby has received the end-of-redo (EOR) log(s)

MRP0: Media Recovery Complete: End-Of-REDO (sfs_stby1)
Resetting standby activation ID 2821924805 (0xa83327c5)
Mon Nov 3 06:53:21 2008
MRP0: Background Media Recovery process shutdown (sfs_stby1)
Mon Nov 3 06:53:22 2008
SUCCESS: diskgroup REGR was dismounted
Mon Nov 3 06:53:22 2008
Switchover: Complete - Database shutdown required (sfs_stby1)
Mon Nov 3 06:53:22 2008
Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN

And correspondingly in the standby alert log file you should see messages like this:

Mon Nov 3 06:53:17 2008
Media Recovery Log +REGR2/sfs/archivelog/2008_11_03/thread_1_seq_21.3819.669797593
Identified End-Of-Redo for thread 1 sequence 21
Mon Nov 3 06:53:17 2008
Media Recovery End-Of-Redo indicator encountered
Mon Nov 3 06:53:17 2008
Media Recovery Applied until change 8338654
Mon Nov 3 06:53:17 2008
MRP0: Media Recovery Complete: End-Of-REDO (sfs1)
Resetting standby activation ID 2821924805 (0xa83327c5)
Mon Nov 3 06:53:19 2008
MRP0: Background Media Recovery process shutdown (sfs1)

Verify that the standby database can be switched to the primary role

Query the SWITCHOVER_STATUS column of the V$DATABASE view on the standby database. For example:
SQL> SELECT SWITCHOVER_STATUS
FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY

A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.

Switchover the standby database to a primary

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

Open the new primary database:

SQL> ALTER DATABASE OPEN;

!!!!!!!!After Switchover need delete restore points on both databases!!!!!!
DROP RESTORE POINT SWITCHOVER_START_GRP;

Procedure to Change the Hostname of the Virtual Machine Oracle E-Business Suite, Release 12.2.4

1. Log in as the oracle user.

2. Source the runtime environment:
$ source  /u01/install/VISION/EBSapps.env Run

3. Execute the following command:
$ $INST_TOP/admin/scripts/adadminsrvctl.sh start

4. Execute the following command:
$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

5. Source the patch environment in the patch file system:
$ source /u01/install/VISION/EBSapps.env Patch

6. Execute the following command:

$ $INST_TOP/admin/scripts/adadminsrvctl.sh start forcepatchfs

7. Execute the following command:
$ $INST_TOP/admin/scripts/adpreclone.pl appsTier

8. Execute the following command to stop the Oracle E-Business Suite application tier:
$ /u01/install/VISION/scripts/stopvisionapps.sh

9. Execute the following command to stop the Oracle E-Business Suite database tier:
$ /u01/install/VISION/scripts/stopvisiondb.sh

10. Execute either one of the following commands as the root user:
# /u01/install/scripts/configstatic.sh
Or
# /u01/install/scripts/configdhcp.sh

11. Execute the following command as the root user:
# /u01/install/VISION/scripts/visiondbconfig.sh

12. Execute the following command as the root user:
# /u01/install/VISION/scripts/visionappsconfig.sh

ps:

weblogic password - welcome1

apps password - apps

pss:

i got error

Target System Port Pool [0-99] : RC-00201: Error: Not a valid port pool number

Upgrade Oracle 10.2.0 to 11.2.0 Tips

While installing you got:
BEGIN wmsys.owm_mig_pkg.moveWMMetaData; END;
*
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at "WMSYS.OWM_MIG_PKG", line 1579
ORA-06512: at "WMSYS.OWM_MIG_PKG", line 1596
ORA-06512: at line 1

ignore this accoding to
ORA-00942 during database upgrade of Oracle Workspace Manager (Doc ID 1399508.1)

public synonym X$KGLLK and invalid view SYS.X_$KGLLK can be dropped in 11G.
So drop the views and any synonyms related to $kslei as they are not used in 11g.
see Invalid X_$ Views & Synonyms After Upgrading to 11g (Doc ID 878623.1)

Create oracle readonly user for all schemas (including system)

sqlplus "/as sysdba"

create role OIM_REPORTER;

-- Assigning Privileges to role
set pagesize 0
spool grant_ro.sql
select 'grant select on '||owner||'.'||table_name||' to OIM_REPORTER;' from all_tables;
select 'grant select on '||owner||'.'||view_name||' to OIM_REPORTER;' from all_views;
spool off
-- Execute it
@grant_ro.sql

CREATE USER ro_user  PROFILE "DEFAULT"
    IDENTIFIED BY "somepassword" DEFAULT TABLESPACE "USERS"
    TEMPORARY TABLESPACE "TEMP"
    ACCOUNT UNLOCK;
-- Permit the user connect to database
GRANT CREATE SESSION, ALTER SESSION TO ro_user;
-- Assigning role to user
GRANT OIM_REPORTER TO ro_user;

Note:
If you create some new tables you have to grant the permission to role.

ORA-12008 ORA-00904 ORA-06512 Oracle bug 10259677

Bug in Oracle 11.2.0.3

Workaround:

Set _replace_virtual_columns=FALSE for the refresh.

Oracle Database Standard Support don't include Technical SR

If your problem is ERROR: ORA 600 - it is Technical problem and SR must be opened as Technical SR

Oracle Grid Standalone update 11.2.0.3 to 11.2.0.4

Backup ASM spfile
$srvctl config asm
ASM home: /u01/app/oracle/product/11.2.0/grid
ASM listener: LISTENER
Spfile: +DATA/asm/asmparameterfile/registry.253.811613369
ASM diskgroup discovery string: /dev/oracleasm/disks/*

$asmcmd

spbackup +DATA/ASM/ASMPARAMETERFILE/REGISTRY.253.811613369 /home/oracle/init+ASM.ora.backup

Backup OLR:
The default backup location for the OLR is in the path Grid_home/cdata/host_name

#ocrconfig –local –manualbackup

To restore OLR:
# crsctl stop crs
# ocrconfig -local -restore file_name
# ocrcheck -local
# crsctl start crs
$ cluvfy comp olr

Begin update
Shutdown the database, oem.
. oraenv prompt dbsid
$emctl stop dbconsole
$srvctl stop database -d dbsid

$unset ORA_CRS_HOME
$unset ORACLE_BASE
$unset ORACLE_HOME
$unset ORACLE_SID
Recommended practice is to upgrade an Oracle ASM instance with Oracle Universal Installer or asmca (after install new GI home) ./runInstaller

Confirm that asm, listener, database, oem are running.
. oraenv
+ASM
$crsctl stat res -t

. oraenv
dbsid
$srvctl start database -d dbsid
$emctl start dbconsole

Oracle update 11.2.0.3 to 11.2.0.4

I have Grid Standalone installation 11.2.0.3 and Oracle Database 11.2.0.3
I plan update to 11.2.0.4
Patching end date for 11.2.0.3 is 27-Aug-2015.

1. Need PSU (Doc ID 1392633.1) and Latest Opatch to apply.

Oracle Grid Infrastructure Patch Set Update 11.2.0.3.8 (Includes Database PSU 11.2.0.3.8) - 17272731

Readme

2. Download Patch Set 11.2.0.4 13390677

Pre-Upgrade Utility Note 884522.1

Use DBUA for out-of-place installation

to be continued ...

scsi_verify_blk_ioctl: xx callbacks suppressed, sending ioctl 2285 to a partition

Oracle UEK2 kernel (2.6.39-xxx):
Warning
scsi_verify_blk_ioctl: xx callbacks suppressed
sending ioctl 2285 to a partition!

can be ignored

https://support.oracle.com/epmos/faces/DocumentDisplay?id=1543759.1

DataPump Import With Object Types Fails With Errors ORA-31693 ORA-2354 ORA-39779 ORA-00600

Error:
ORA-31693: "AAA"."BBB"
ORA-00600:  [kpudpxcs_getCol_ref_4], [Imgver=8 InputStrmVer=9 Name=XXX], [], [], [], [], [], [], [], [], [], []

 or

ORA-39779:

Solution:
Please pre-create the object type(in collumn XXX table "AAA"."BBB" ) in the target database and then retry the DataPump import with the following additional parameter:
TRANSFORM=oid:n

https://support.oracle.com/epmos/faces/DocumentDisplay?id=404234.1

dbv script for ASM datastore

select 'dbv file='''||file_name||''' blocksize='||df2.BLOCK_SIZE||' userid=sys/xxx logfile=dbv-'||tablespace_name||'.log' from dba_data_files df,v$datafile df2
where  df.file_id = df2.FILE#

minimum size oracle bigfile tablespace

for normal tablespace:
Metalink ID 153869.1
CREATE TABLESPACE minimum_data DATAFILE '/u00/minimum_data.dbf' SIZE 88k LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO


for bigfile tablespace:
CREATE BIGFILE TABLESPACE minimum_data DATAFILE '/u00/minimum_data.dbf' SIZE 145k LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO

RDAC and Oracle Linux 6.4 boot from SAN DS35xx

Check  kernel-uek-devel package
# rpm -qa| grep kernel-uek-devel
kernel-uek-devel-2.6.39-400.17.2.el6uek.x86_64

Download latest driver from:
RDAC driver homepage

Compile driver:
make
make install

Use mpp-2.6.39-400.17.2.el6uek.x86_64.img in catalog /boot
or
Make initramfs(before make backup of original initramfs):
dracut -f

Check it.

/boot/efi/EFI/redhat/grub.conf:

title Oracle Linux Server (2.6.39-400.17.2.el6uek.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.39-400.17.2.el6uek.x86_64 ro root=/dev/mapper/vg_db06-lv_root rd_NO_LUKS rd_LVM_LV=vg_db06/lv_root LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16   KEYBOARDTYPE=pc KEYTABLE=u
s rd_NO_DM rhgb quiet
        initrd /mpp-2.6.39-400.17.2.el6uek.x86_64.img

or

title Oracle Linux Server (2.6.39-400.17.2.el6uek.x86_64)
        root (hd0,1)
        kernel /vmlinuz-2.6.39-400.17.2.el6uek.x86_64 ro root=/dev/mapper/vg_db06-lv_root rd_NO_LUKS rd_LVM_LV=vg_db06/lv_root LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16   KEYBOARDTYPE=pc KEYTABLE=u
s rd_NO_DM rhgb quiet

        initrd /initramfs-2.6.39-400.17.2.el6uek.x86_64.img

Note: Modifying the /etc/modprobe.conf file to configure the HBA driver to be a
non-failover driver as explained previously is not necessary if you plan to use RDAC as the
multipathing driver. The reason is that RDAC will put and activate the same parameter into
the file /opt/mpp/modprobe.conf.mppappend during the RDAC installation to force the
QLogic driver to load the non-failover mode.


If any changes are made to the MPP configuration file (/etc/mpp.conf) or persistent binding
file (/var/mpp/devicemapping), then the mppUpdate executable can be used to rebuild the
RAMdisk.



After reboot:

[root@db06 ~]# lsmod| grep mpp
mppVhba               139668  3
mppUpper              157843  1 mppVhba
[root@db06 ~]# modinfo mppVhba
filename:       /lib/modules/2.6.39-400.17.2.el6uek.x86_64/kernel/drivers/scsi/mppVhba.ko
supported:      yes
version:        09.03.0C05.0642
license:        GPL
description:    MPP Virtual HBA Driver
author:         NetApp, Inc.
srcversion:     8FA0CDD56E4F43D69A5FB7A
depends:        mppUpper
vermagic:       2.6.39-400.17.2.el6uek.x86_64 SMP mod_unload modversions
[root@db06 ~]# modinfo mppUpper
filename:       /lib/modules/2.6.39-400.17.2.el6uek.x86_64/kernel/drivers/scsi/mppUpper.ko
supported:      yes
version:        09.03.0C05.0642
license:        GPL
description:    MPP Upper Level Driver
author:         NetApp, Inc.
srcversion:     A44FFC021138064A26E1CC7
depends:
vermagic:       2.6.39-400.17.2.el6uek.x86_64 SMP mod_unload modversions


[root@db06 /]# ls -lR /proc/mpp
/proc/mpp:
total 0
dr-xr-xr-x 4 root root 0 Mar 28 16:12 ds3524

/proc/mpp/ds3524:
total 0
dr-xr-xr-x 3 root root 0 Mar 28 16:12 controllerA
dr-xr-xr-x 3 root root 0 Mar 28 16:12 controllerB
-rw-r--r-- 1 root root 0 Mar 28 16:12 virtualLun0
-rw-r--r-- 1 root root 0 Mar 28 16:12 virtualLun1

/proc/mpp/ds3524/controllerA:
total 0
dr-xr-xr-x 2 root root 0 Mar 28 16:12 qla2xxx_h1c0t0

/proc/mpp/ds3524/controllerA/qla2xxx_h1c0t0:
total 0
-rw-r--r-- 1 root root 0 Mar 28 16:12 LUN0
-rw-r--r-- 1 root root 0 Mar 28 16:12 LUN1

/proc/mpp/ds3524/controllerB:
total 0
dr-xr-xr-x 2 root root 0 Mar 28 16:12 qla2xxx_h0c0t0

/proc/mpp/ds3524/controllerB/qla2xxx_h0c0t0:
total 0
-rw-r--r-- 1 root root 0 Mar 28 16:12 LUN0
-rw-r--r-- 1 root root 0 Mar 28 16:12 LUN1

[root@db06 /]# mppUtil -a

Hostname    = db06.core.kran
Domainname  = (none)
Time        = GMT 03/28/2013 08:20:49

---------------------------------------------------------------
Info of Array Module's seen by this Host.
---------------------------------------------------------------
ID              WWN                      Type     Name
---------------------------------------------------------------
 0      60080e50002f084800000000510057b6 FC     ds3524
---------------------------------------------------------------
[root@db06 /]# /opt/mpp/lsvdev
        Array Name      Lun    sd device
        -------------------------------------
        ds3524          0     -> /dev/sda
        ds3524          1     -> /dev/sdb

Certification Information for Oracle Database on Linux x86-64

Metalink [ID 1304727.1]

RMAN-06094

If you don't backup tablespace because, it is test, for example:

CONFIGURE EXCLUDE FOR TABLESPACE 'dr2006';

You will get rman error then try to recover database:

RMAN-06094: datafile 32 must be restored

Just recover without it:

RMAN> recover database skip tablespace dr2006,dr2007,dr2008,dr2009,dr2010;

Before alter database open resetlogs

alter database datafile 31 offline drop;

ORA-01157: cannot identify/lock data file 31 - see DBWR trace file
ORA-01110: data file 31: '/u13/oradata/bp/dr2006.dbf'

ORA-00600 [kksfbc-reparse-infinite-loop]

1. Check invalid object
select do.obj# d_obj,do.name d_name, do.type# d_type,
po.obj# p_obj,po.name p_name,
to_char(p_timestamp,'DD-MON-YYYY HH24:MI:SS') "P_Timestamp",
to_char(po.stime ,'DD-MON-YYYY HH24:MI:SS') "STIME",
decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X
from sys.obj$ do, sys.dependency$ d, sys.obj$ po
where P_OBJ#=po.obj#(+)
and D_OBJ#=do.obj#
and do.status=1 /*dependent is valid*/
and po.status=1 /*parent is valid*/
and po.stime!=p_timestamp /*parent timestamp not match*/
order by 2,1;

return AQ_EVENT_TABLE

2. alter table AQ_EVENT_TABLE upgrade;

3. @?/rdbms/admin/utlrp.sql

OPENVZ ORACLE RHEL4 x86_64 VM rpm prerequisite

vzyum vpsid install binutils compat-db gcc gcc-c++ glibc \
glibc-common libstdc++ libstdc++-devel gnome-libs make \
pdksh sysstat libaio xscreensaver openmotif21 xorg-x11-xfs \
usbutils urw-fonts shared-mime-info perl-libwww-perl \
perl-XML-Parser perl-URI perl-HTML-Tagset perl-HTML-Parser \
patch lvm2 intltool libIDL libart_lgpl libbonobo xterm \
libcap libcroco libgnomecanvas libexif libgnomecups \
libgnomeprint22 libsoup libwnck libxklavier compat-libstdc++-33