PARMVNT_SHD Performance Issues

[former_member229542]

Hi guys,

While performing an ERP 6 EHP7 Upgrade, during PARMVNT_SHD step, Upgrade is taking up to 24 hrs to complete.

Basically there are no errors, but its seems a very long time and this would affect a lot planning Downtime for Productive System

This Upgrade was made on a Sandbox with the same size as Production which is around 6.8 TB

This system runs under Solaris 10 / Oracle 11.0.2.3

After analyzing many notes, especially those regarding performance I couldnt figure out what is the reason one particular Index creation is taking so long

8 tp processes were defined to run in parallel, and all other finished really quick, while only one tp #3 had long time running when creating indexes

When reading output log for tp process #3, yo can notice that index creating for table BKPF took mostly all 24 hours to complete

I have extracted each index creation so, you can see how long it takes

3 ETP000 INDEX "BKPF~0" ON "BKPF~"

3 ETP356 executed ( "07:47:17" )

3 ETP000 INDEX "BKPF~1" ON "BKPF~"

3 ETP356 executed ( "03:23:13" )

3 ETP000 INDEX "BKPF~3" ON "BKPF~"

3 ETP356 executed ( "03:13:45" )

3 ETP000 INDEX "BKPF~3" ON "BKPF~"

3 ETP356 executed ( "02:30:34" )

3 ETP000 INDEX "BKPF~4" ON "BKPF~"

3 ETP356 executed ( "00:44:16" )

3 ETP000 INDEX "BKPF~5" ON "BKPF~"

3 ETP356 executed ( "00:33:04" )

3 ETP000 INDEX "BKPF~6" ON "BKPF~"

3 ETP356 executed ( "00:31:21" )

3 ETP000 INDEX "BKPF^BUT" ON "BKPF~"

ETP356 executed ( "00:23:09" )

3 ETP000 INDEX "BKPF~Z1" ON "BKPF~"

13 ETP356 executed ( "00:41:22" )

3 ETP000 INDEX "BKPF^Z2" ON "BKPF~"

3 ETP356 executed ( "00:47:11" )

3 ETP000 INDEX "BKPF^Z55" ON "BKPF~"

3 ETP356 executed ( "00:44:39" )

3 ETP000 INDEX "BKPF^Z71" ON "BKPF~"

3 ETP356 executed ( "00:56:59" )

3 ETP000 INDEX "BKPF^Z72" ON "BKPF~"

ETP356 executed ( "00:44:20" )

Is there a way to avoid index creation for this particular table, or why Upgrade Tool decide to reindex this table

Best

Martin

[hemanth2 · Accepted solution]

Hi martin,

Hope you are doing good.

Looks like a conversion issue when the table size is huge (BKPF,BSEG etc.)

Please have a look at note 1283197 for the options available in such cases.

Hope this helps.

_____________

Kind Regards,

Hemanth

[former_member229542 · Accepted solution]

Hi Hemanth

I have read this note 1283197, which was implemented in the system before the Upgrade. In this case, the table is not converted which would occur in step PARCONV_UPG, nevertheless the indexes are recreated.

I do believe its due cluster table BSEG is adjusted during SPDD, causing a re-index. So I'm aiming to avoid this reindexation.

[Reagan]

>>Is there a way to avoid index creation for this particular table, or why Upgrade Tool decide to reindex this table<<

I believe this is possible by updating the PRTEXT filed of the TATAF~ table.

Cheers

RB

[former_member229542]

Hi Benjamin,

Thank for this valuable input, my concern is i have to somehow manually stop the upgrade when this table is filled, and before the recreation of indexes.

I will check with SAP Support how can I manually skip this index

[hemanth2]

Hi martin,

Yes, it would be possible that if the index is non unique, then you can skip this by deleting the TATAF entries; but you need to recreate the skipped indexes after the upgrade.

Perhaps you can also check with the DB team about this and the Database performance.

Hope this helps.

_____________

Kind Regards,

Hemanth

[Reagan]

>>my concern is i have to somehow manually stop the upgrade when this table is filled<<

You can use a breakpoint in SUM to stop the upgrade before that phase. Check the SUM guide.

Cheers

RB