Archive

Archive for August, 2011

ORA-39083: Object type INDEX_STATISTICS failed to create with error:

August 17, 2011 Leave a comment

I import a schema by impdp. There are errors returned as following.

ORA-39083: Object type INDEX_STATISTICS failed to create with error:
ORA-01403: no data found
ORA-01403: no data found
Failing sql is:
DECLARE IND_NAME VARCHAR2(60);   IND_OWNER VARCHAR2(60);   colname DBMS_METADATA.T_VAR_COLL; BEGIN  DELETE FROM “SYS”.”IMPDP_STATS”;   colname(1) := ‘PLAYER_ID’;  DBMS_METADATA.GET_STAT_INDNAME(‘SPORT’, ‘GEN_PLAYER’, colname, 1, ind_owner, ind_name);   INSERT INTO “SYS”.”IMPDP_STATS” (type, version, flags, c1, c2, c3, c5,
n1, n2, n3, n4, n5, n6, n7, n8, n9,
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.PUT_DDLS [TABLE_STATISTICS]
ORA-06502: PL/SQL: numeric or value error
LPX-00225: end-element tag “HIST_GRAM_LIST_ITEM” does not match start-element tag “EPVALUE”
ORA-06512: at “SYS.DBMS_SYS_ERROR”, line 95
ORA-06512: at “SYS.KUPW$WORKER”, line 7839

Then I import the schema again with “EXCLUDE=STATISTICS”, it works successfully.  After that I gather the schema statistics by command below.

SQL> exec dbms_stats.gather_schema_stats(‘sport’);

Advertisements
Categories: impdp, ORA-XXX

Assign VNET ID

August 8, 2011 Leave a comment

Today, I found that vnet mac-addresses are not matching between guest OS and ldm primary domain configuration. i.e.

At guest OS level, the vnet2 mac-address is “0:14:4f:f8:8a:74”

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vnet2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.100.200 netmask ffffff00 broadcast 192.168.100.255
ether 0:14:4f:f8:8a:74

At Primary Domain, the vnet3 mac-address is “00:14:4f:f9:e9:19 “
# ldm list-bindings ldg2

NETWORK
NAME             SERVICE                     ID   DEVICE     MAC               MODE   PVID VID                  MTU   LINKPROP
vnet2            primary-vsw0                0               00:14:4f:f9:e9:19        1
vnet1            primary-vsw2                1               00:14:4f:f8:8a:74        1

===============================================================

Finally, I found that the ID is used to match the vnet interface at guest OS.

ID=0 –> vnet0, ID=1 –> vnet1, ID=2 –> vnet2

Therefore, I reassign the vnet to guest with ID to make sure the vnet mac-address consistent between guest OS and LDM primary domain

1. Assign the vnet to guest with id

# ldm add-vnet id=0 vnet0 primary-vsw1 ldg2

# ldm add-vnet id=1 vnet1 primary-vsw2 ldg2

# ldm add-vent id=2 vnet2 primary-vsw0 ldg2

# ldm list-bindings ldg2

NETWORK
NAME             SERVICE                     ID   DEVICE     MAC               MODE   PVID VID                  MTU   LINKPROP
vnet1            primary-vsw2                1               00:14:4f:f8:8a:74        1
vnet2            primary-vsw0                2               00:14:4f:f9:e9:19        1
vnet0            primary-vsw1                0               00:14:4f:f9:2b:c4        1

DISK

2. Bind the guest ldg2

# ldm bind ldg2
# ldm start ldg2
LDom ldg2 started

3. Verify the mac-address of guest.

Check them at Guest OS level

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
vnet0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 0.0.0.0 netmask 0
ether 0:14:4f:f9:2b:c4
vnet1: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
inet 0.0.0.0 netmask 0
ether 0:14:4f:f8:8a:74
vnet2: flags=4001000842<BROADCAST,RUNNING,MULTICAST,IPv4,DUPLICATE> mtu 1500 index 2
inet 192.168.100.200 netmask ffffff00 broadcast 192.168.100.255
ether 0:14:4f:f9:e9:19

4. All mac-address are matching set at LDM primary primary

 

Categories: LDom

CRS-0184: Cannot communicate with the CRS daemon

August 4, 2011 Leave a comment

Last week,  a  development 11gR1 RAC cluster couldn’t be started in redhat. When I checked the cluster status with crs_stat -t, it returned “CRS-0184: Cannot communicate with the CRS daemon”. The following was the fixing procedures

1. Check system messages

# cd /var/log

[root@SGRAC1 log]# tail messages
Jul 25 11:48:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5380.
Jul 25 11:49:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5380.
Jul 25 11:49:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5301.
Jul 25 11:49:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5559.
Jul 25 11:50:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5559.
Jul 25 11:50:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5380.
Jul 25 11:50:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5301.
Jul 25 11:51:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5559.
Jul 25 11:51:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5301.
Jul 25 11:51:21 SGRAC1 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.5380.

2.  Check details of cluster messages in /tmp/crsctl.5380.

[root@SGRAC1 log]# cat /tmp/crsctl.5380
clsscfg_vhinit: unable(1) to open disk (/dev/sdc1) <– this shows that it can read disk
Internal Error Information:
Category: 1234
Operation: scls_block_open
Location: open
Other: open failed /dev/sdc1
Dep: 13
Failure 1 checking the Cluster Synchronization Services voting disk ‘/dev/sdc1’.
Not able to read adequate number of voting disks

3. Check raw /dev/sdc1 status

[root@SGRAC1 log]# ls -l /dev/sdc1
brw-r—– 1 root disk 8, 33 Jul 25 11:29 /dev/sdc1 <– this shows that there is no permission for Oracle

4. Change owner to oracle

[root@SGRAC1 log]# chown oracle:dba /dev/sdc1

After that, the cluster was back to normal

 

 

Categories: clusterware