Also please suggest how to drop the index related to this COMC_ATTRIBUTE table.
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
please suggest if the below command in SQL can be used.
drop index SAPSR3. "<indexname>";
also i found two indexes in select statement
SQL> select INDEX_NAME, COLUMN_NAME, COLUMN_POSITION
2 from DBA_IND_COLUMNS where INDEX_NAME
3 IN (select INDEX_NAME
4 from DBA_INDEXES
5 where TABLE_NAME = 'COMC_ATTRIBUTE' and UNIQUENESS = 'UNIQUE');
INDEX_NAME
------------------------------
COLUMN_NAME
----------------------------------------------------------------------------
COLUMN_POSITION
---------------
COMC_ATTRIBUTE~0
ATTR_GUID
1
COMC_ATTRIBUTE~UNI
ATTR_ID
1
INDEX_NAME
------------------------------
COLUMN_NAME
----------------------------------------------------------------------------
COLUMN_POSITION
---------------
please suggest if "COMC_ATTRIBUTE~0" & "COMC_ATTRIBUTE~UNI" needs to be droped.
↧
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
in addition to above logs: SQL shows below enteris in obj.
SQL> select index_name, owner, visibility from dba_indexes where table_name='COM
C_ATTRIBUTE';
INDEX_NAME OWNER VISIBILIT
------------------------------ ------------------------------ ---------
COMC_ATTRIBUTE~UNI SAPSR3 VISIBLE
COMC_ATTRIBUTE~0 SAPSR3 VISIBLE
SQL> select OBJ#, DATAOBJ#, NAME from obj$ where NAME like '%COMC_ATTRIBUTE%';
OBJ# DATAOBJ# NAME
---------- ---------- ------------------------------
63414 63414 COMC_ATTRIBUTE
63419 63419 COMC_ATTRIBUTE~0
63422 63422 COMC_ATTRIBUTE~UNI
63423 63423 COMC_ATTRIBUTE_T
63426 63426 COMC_ATTRIBUTE_T~0
146492 146492 COMC_ATTRIBUTE_T~
146494 146494 COMC_ATTRIBUTE_T^0
146834 146834 COMC_ATTRIBUTE~
146835 146835 COMC_ATTRIBUTE^0
146836 146836 COMC_ATTRIBUTE^UNI
170856 COMC_ATTRIBUTE_T
OBJ# DATAOBJ# NAME
---------- ---------- ------------------------------
172402 COMC_ATTRIBUTE
12 rows selected.
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
The drop index statement you have shown is the correct one for an Oracle database. I would drop the conflicting index and repeat the phase in SUM. If that doesn't help the then create a non unique index and continue with the upgrade.
Also are you reading all the SAP notes mentioned in the note I have given to you ? Read the reference note 1795072 as well.
Cheers
Reagan
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
Hi Benjamin,
i have dropped the conflict index but still not able to move ahead.
i have checked with all SAP notes mentioned in the snote 1872729:
According to that am in upgrade phase so following the same.
You are in the upgrade phase
- Drop the index on the database (if you use a shadow system don't forget to drop the index also in the shadow table).
- Proceed with the upgrade and finish it.
- Run the report Z_REPAIR_COMC_ATTRIBUTE from note 601757.
- Recreate the index on the database.
- Than run the correction report form note 1795072.
- For error prone entries function modul COM_ATTRIBUTE_TAB_DELETE can be used to delete entries in table COMC_ATTRIBUTE.
- If you upgrade to CRM EHP3 run report ECRM_DEL_COMC_ATTRIBUTE_UPG.
As per point 1:
need to drop the index on database. for this i have checked in database for conflicting indexec for table COM_ATTRIBUTE
for the same i ran below commands to find them and drop the index.
SQL> select index_name, owner, visibility from dba_indexes where table_name='COM
C_ATTRIBUTE';
INDEX_NAME OWNER VISIBILIT
------------------------------ ------------------------------ ---------
COMC_ATTRIBUTE~UNI SAPSR3 VISIBLE
COMC_ATTRIBUTE~0 SAPSR3 VISIBLE
SQL> select OBJ#, DATAOBJ#, NAME from obj$ where NAME like '%COMC_ATTRIBUTE%';
OBJ# DATAOBJ# NAME
---------- ---------- ------------------------------
63414 63414 COMC_ATTRIBUTE
63419 63419 COMC_ATTRIBUTE~0
63422 63422 COMC_ATTRIBUTE~UNI
63423 63423 COMC_ATTRIBUTE_T
63426 63426 COMC_ATTRIBUTE_T~0
146492 146492 COMC_ATTRIBUTE_T~
146494 146494 COMC_ATTRIBUTE_T^0
146834 146834 COMC_ATTRIBUTE~
146835 146835 COMC_ATTRIBUTE^0
146836 146836 COMC_ATTRIBUTE^UNI
170856 COMC_ATTRIBUTE_T
OBJ# DATAOBJ# NAME
---------- ---------- ------------------------------
172402 COMC_ATTRIBUTE
12 rows selected.
SQL> drop index "SAPSR3"."COMC_ATTRIBUTE~UNI";
Index dropped.
SQL> drop index "SAPSR3"."COMC_ATTRIBUTE~0";
Index dropped.
but still the error is same.
please suggest how to create a non unique index.
Also snote 1795072. has to applied after upgradation by following nxt steps as per snote 1872729.
↧
↧
Re: SUM main_transexec/tabim_trans took long time
Dear
Log says it is running from many hours so i can i login to app level and check sm21 st22 dupms i can cpu usage from os it says it occupies 33% of total cpu all this use by upgrade only bcaZ as system down no user log in
Regards
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
Hi Benjamin,
Please shuggest how to identify shadow tables am not able to identify them.
the queries outputs are below:
SQL> select index_name, owner from dba_indexes where table_name like 'COMC_ATTRI
BUTE%';
INDEX_NAME OWNER
------------------------------ ------------------------------
COMC_ATTRIBUTE_T~0 SAPSR3
COMC_ATTRIBUTE_T^0 SAPSR3
COMC_ATTRIBUTE^0 SAPSR3
COMC_ATTRIBUTE^UNI SAPSR3
SQL> select prtext from sapsr3.tataf where tabname='COMC_ATTRIBUTE';
no rows selected
SQL>
i have also tried changing the index COMC_ATTRIBUTE^UNI to non-unique via SE11 tcode in the current sap system, but still not luck.
Kindly suggest.
Thanks.
↧
Re: Checks after phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC were negative!
Again I see those indexes present in the system. Have you dropped them ?
Is the shadow system running? if yes connect to the shadow and check the table tataf using Tx SE16.
↧
Re: Update and insert sequence failed due to conflicting unique indexes on table /IWFND/I_MED_SRH (please read OSS note 626915 for details)
Have you tried to drop the index from the DB level ?
Connect to the shadow system and call Tx SE16 - TATAF and enter /IWFND/I_MED_SRH in the TABNAME field and provide the output.
Regards
Reagan
↧
↧
Re: error in TABIM_TRANS - Inconsistent status for buffer creation
Not yet, I'm still on this break-point.
SAP Oss requested WTS connection, they were already there, but I still have no answer how it happened and what to do to fix it.
↧
Re: SUM main_transexec/tabim_trans took long time
are the logs getting updated in the <Upgrade directory>/abap/tmp ?
If possible supply the latest log from the <Upgrade directory>/abap/log directory.
↧
SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
Dears,
We are performing EHP5->EHP7 upgrade using latest SUM 11 path 7 it is SqlServer 2012 R2 and windows 2008 Server R2.
Severe error(s) occurred in phase MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC!
Last error code set: Inconsistent status for buffer creation
Log PHASES
1 ETQ200 Executing actual phase 'MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC'.
1 ETQ399 Phase arguments:
2 ETQ399 Arg[0] = 'SHDINCIMP.BUF'
2 ETQ399 Arg[1] = 'SHDALLIMP.TP0'
2 ETQ399 Arg[2] = 'INCIMP.BUF'
2 ETQ399 Arg[3] = 'parallelgroups;optimizeimport'
1 ETQ399 Using error summary log 'SHDALLIMP.ELG'.
1 ETQ399 Executing putsteps 'HK'.
4 ETQ380 computing toolpath for request "TP_IMPORT_TO_SHADOW"
4 ETQ381 request "TP_IMPORT_TO_SHADOW" means "tp calles R3trans with import to shadow"
4 ETQ382 translates to group "R3UP_TOOL_GROUP_SHD"
4 ETQ399 Requirement for tp maps to 'exe'
4 ETQ383 translates to path "E:\usr\SUM\abap\exe"
1EETQ399 Last error code set is: Inconsistent status for buffer creation
1EETQ204 Upgrade phase "SHADOW_IMPORT_INC" aborted with severe errors ("20141025105847")
I cannot find anything useful to troubleshoot this issue...
Any ideas how to fix this?
↧
Re: EHP7 downtime phase NEWBAS/JOB_RSUPGCUA_PROD problem
Not sure but try to add to start profile parameters to start standalone enqueue server like:
Start_Program_XX = local $(_EN) pf=$(DIR_PROFILE)$(DIR_SEP)
_EN = $(DIR_EXECUTABLE)$(DIR_SEP)enserver$(FT_EXE)
You can also raise OSS message to SAP to get more qualified help.
↧
↧
Re: Update and insert sequence failed due to conflicting unique indexes on table /IWFND/I_MED_SRH (please read OSS note 626915 for details)
After dropping the index from the DB level its still giving same error.
And SE16 is giving dump as SAP_BASIS patch upgrade is not yet complete.
Thanks,
↧
Re: SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
Hello,
Could you please attach the SAPupConsole.log here. I suspect that some errors were ignored in previous phases which are now causing the issue.
Regards,
Gaurav
↧
Re: Update and insert sequence failed due to conflicting unique indexes on table /IWFND/I_MED_SRH (please read OSS note 626915 for details)
If you are unable to use Tx SE16 then could you query the table from the DB level ?
Reagan
↧
Re: SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
Hi,
I ignored error in step MAIN_SHDRUN/ACT_UPG.
Only one object was not active in MAIN_SHDRUN / phase ACT_UPG
The objetct is ISPS_BPST_DI
Was that the cause of this error?
Attached log.
↧
↧
Re: SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
Hello Gaurav,
I had to follow the following KBA:
1909524 - Error in ACT_TRANS phase (Tables M_PREMA, V_7BR_PREMA and V_T7BRAP )
-> Continue the upgrade by choosing the option 'Accept non-severe errors and repeat phase MAIN_SHDRUN/ACT_UPG' in SUM tool.
Very nice...
Regards,
Sebastian
↧
Re: SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
It seems that ACT_UPG did not create the buffer file SHDIMPINC.BUF properly. So now phase SHADOW_IMPORT_INC is failing .
↧
Re: SUM Error MAIN_SHDIMP/SUBMOD_SHDIMP/SHADOW_IMPORT_INC
Hello Luciano,
in my case SAP has confirmed note "2083179 - Problems Ignoring Phases in SUM SP11 PL7".
I have to reset the update.
Regards,
Sebastian
↧