ERROR => ORA-00904 occurred at SQL stmt

[Former Member]

Hi,

We are doing 7.3 ehp1 upgrade in our BW system.  During ACT_UPG phase, after 3 dag i get This error on log dev_wll:

***************

Connection 1 opened (DBSL handle 1)
S 
S Sat Sep 08 14:04:46 2012
S  found spool memory service RSPO-ACTIONS at 000000003039A4B0
D 
D Mon Sep 10 08:42:57 2012
D  GuiStatus: table test
M 
M Mon Sep 10 08:43:12 2012
M  ThSick: rdisp/system_needs_spool = false
M  10.09.2012 06:43:12.184 PID=4668, TID=4664 SapTimer info. v1.119 SynchCount:1 , OwnerPid: 4980, ErrsCount: 0, SapTime-WindowsUtcTime=-206 millisec (max=-3618), Nosync=130071 sec, SynchsPerDay=0.500000, MaxQpcTimeMinusWindowsTimeMismatch:  -3551 millisec, TotalTimeCorrection=+3618 millisec, QpcTime-WindowsUtcTime=-3824 millisec (*)
B 
B Mon Sep 10 08:43:13 2012
B  dbmyclu : info : my major identification is 172786018, minor one 1101.
B  dbmyclu : info : Time Reference is 1.12.2001 00:00:00h GMT.
B  dbmyclu : info : my initial uuid is E1FB12CA49FBBDF180370050568852AD.
B  dbmyclu : info : current optimistic cluster level: 0
B  dbmyclu : info : pessimistic reads set to 2.
M 
M Mon Sep 10 08:43:18 2012
M  ThEMsgArrived: sysmsg_for_rfc = 0
L 
L Mon Sep 10 08:43:44 2012
L  SSMJOB: > There are no active profiles of criteria type 'SSMJOB'
B 
B Mon Sep 10 08:44:08 2012
B  dbdynpdb2: table DYNPSOURCE not found => synonym in shadow instance?
C     OCIStmtExecute() failed with -1=OCI_ERROR
C     SQL error 904:
C  *** ERROR => Error 904 in stmt_fetch() from oci_execute_stmt(), orpc=0
[dbsloci.c    16604]
C  {root-id=0050568852AD1ED1BEE2582365A32037}_{conn-id=00000000000000000000000000000000}_0

C  *** ERROR => ORA-00904 occurred at SQL stmt (parse error offset=7)
[dbsloci.c    16622]
C  {root-id=0050568852AD1ED1BEE2582365A32037}_{conn-id=00000000000000000000000000000000}_0

C  Dump statement cache:
C  sc_p=00000000078833D0,no=112,idc_p=0000000000000000,con=0,act=1,slen=32,smax=256,#vars=0,stmt=0000000032696440,table=DYNPSOURCE                   
C  SELECT VERSION FROM "DYNPSOURCE";
C  Dump statement cache:
C  sc_p=00000000078833D0,no=112,idc_p=0000000000000000,con=0,act=1,slen=32,smax=256,#vars=0,stmt=0000000032696440,table=DYNPSOURCE                   
C  Dumping DBSL stmt. cache:
C  sc=078833D0, scp=14EED010, ups_sc=0000NULL, stp=32936818, r_c=0
C  prep=0, lit=0, nsql=0, lobret_cnt=0, fae_cnt=0, xop=1, dbcnt=0
C  IN : col_cnt=0, row_max=1, row_xcnt=0, row_pcnt=0, row_i=0, row_total=0,
C       row_upto=4294967295, row_size=0, vda_max=32, bound=0, itp=0000NULL, vda_arr=328A2760
C       lob_cnt=0, lob_max=0, lob_pw_cnt=0,  lob_arr=0000NULL, rows_ret=0
C  OUT: col_cnt=1, row_max=1, row_xcnt=1, row_pcnt=0, row_i=0, row_total=0,
C       row_upto=1, row_size=4, vda_max=32, bound=1, itp=022E2F60, vda_arr=328A2FF0
C       lob_cnt=0, lob_max=0, lob_pw_cnt=0,  lob_arr=0000NULL, rows_ret=0
C  SELECT VERSION FROM "DYNPSOURCE";
B  dbdynpdb2: table DYNPSOURCE has no VERSION column, dbsl_rc = 99

Thanks for  any help.

[former_member189725 · Accepted solution]

Can you check in dba_tables , the tables DYNPSOURCE and DYNPSOURCE~ exists or not .

Then check if both the tables have a field named VERSION (desc SAPSR3.DYNPSOURCE) . Then check in dba_synonyms if , DYNPSOURCE exist.

If everything looks fine , then update the kernel to the latest under exenew subdirectory under the upgrade directory.

Regards

Ratnajit

[Former Member · Accepted solution]

Can you pleas guid me where can I check this to tables are  exist.

On se 11 i can see the DYNPSOURCE exist.

Thanks

[Former Member · Accepted solution]

Hello,

I am upgradeing BW, I can see the  field named VERSION is just eksist on shadow instance on  DYNPSOURCE  table.

Is it a new field the will be added during opdrade?

Thanks

[former_member189725 · Accepted solution]

In your source version , there is an inconsistency with runtime (nametab) object and dictionary object.

What is the error you are getting in the upgrade tool .

Also an inconsistency in the DYNPSOURCE table will put you into issues while running a system normally. Are you getting any errors because of this ?

The version field should exist in your source version as well . What is the source version of the upgrade?

Regards

Ratnajit

[Former Member · Accepted solution]

There is no inconsistency on source instance. And I have not this  version field on source instanc.

I am going from 7.0 ehp to 7.3 ehp1.

I am on oracle 11.

Thanks

[former_member189725 · Accepted solution]

In the shadow instance is the DYNPSOURCE consistent ?

If yes , follow the steps below from the SAP note I mentioned

To eliminate the inconsistency in tables, proceed as follows:

a) Log on as user DDIC.

b) Call transaction SE14.

c) Enter the name of the table and choose "Edit".

d) In the menu, choose: "Table" -> "Reconstruct".

e) Confirm the execution as an emergency repair.

f) Select the radio button for the processing type as follows: "Direct" or (for very large tables) "Background".

g) Select the "Save data" radio button.

1. h) Choose "Activate and adjust database" to activate the table.

Make sure you have a consistent backup of the database before you started the upgrade.

Regards

Ratnajit

[Former Member · Accepted solution]

Here is display log after I  Confirm the execution as an emergency repair:

Nametab reconstruction table DYNPSOURCE (DDIC/10.09.12/12:32)
Table set to read-only
Differences between DB and nametab for table DYNPSOURCE :
No differences found between database and nametab
The following generated nametab and associated DB

                    Database                 Nametab
Column     Type       Lngth KeyPos. Type       Lngth KeyPos

PROGNAME VARCHAR2 0120 0001 CHAR 0080 0001
DYNPNUMBER VARCHAR2 0012 0002 NUMC 0008 0002
R3STATE VARCHAR2 0003 0003 CHAR 0002 0003
FIELDINFO BLOB 0000 0000 RAWSTRING 0008 0000
LOGICINFO BLOB 0000 0000 RAWSTRING 0008 0000
EXTENSIONS BLOB 0000 0000 RAWSTRING 0008 0000
Nametab reconstructed from database definition
Nametab must be activated to ensure completeness

I can not mad ny changwe on shadow the Table set to read-only.

Should I stop upgrade and unlock shadow and run SE14 again?

[former_member189725 · Accepted solution]

Oh sorry I forgot to mention .

If the table DYNPSOURCE is consistent in the shadow schema , then perform the actions in the mentioned in the note in the main instance , not in the shadow instance.

In the main instance , the runtime object for the table is inconsistent. So do the above in the main instance as user DDIC.

Regards

Ratnajit

[Former Member · Accepted solution]

Should I restart my upgrade after applying the note correction on main instance?

[former_member189725 · Accepted solution]

Before you do the change , check the number of entries in DYNPSOURCE . Then do the change as per the note on the main instance as user DDIC. Then check the number of entries again . Use "Save Data" button in SE14 when you do this is very important.

Then once the table is consistent , go ahead with the upgrade.

Regards

Ratnajit

[Former Member · Accepted solution]

Thanks for help.

[Former Member]

Hi,

Check this note Note 731 - Collective note: ORA-00904

Thanks,

Venkat

[Former Member]

Hello Venkat,

Thanks for reply I did checked  the table :

"SE11 -> DYNPSOURCE -> Execute -> Utilities -> Runtime Object

-> Check".

And that is inconsistent on this table.

There is A active runtime object and Active source has inconsisten.

VERSION do(es) not exist VERSION 4 0 INT1 1 1 0 90 3 164 10 b 0 00000000 00000000 00000000 00000000  0    

Any idea how can I solve this kind of inconsistens?

Thanks

[former_member189725]

This seems to a very critical issue as the upgrade is running .

You might just have to restore the database and start from scratch again .

I suggest you follow the SAP note Note 1248769 - Inconsistency between database and ABAP Dictionary

after you restore the database backup .

As per the note you should not do the steps mentioned during an upgrade and especially in the shadow schema . As the shadow schema has already been built as a copy of source .

Regards

Ratnajit