speed up prtime dbreorg

Our PRTIME table has more than 70 million records and one dbreorg we did lately took more than a day to finish in dev environment. dbreorg -F is not working and table dump/reload still occurs with that option in. Has anyone here encountered similar issue and come up with a workaround to speed up the process? Thanks.

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

unknown

This is what we had to do for our MS SQL database. We created a special location/ disk for the LOG and TEMPDB files that were large enough to hold the complete file. These were separate physical disk so no sharing of disk IO. Otherwise the DBreog would run out of space and / or would keep taking extents. We temporarily did this with our last upgrade and after the upgrade rest to our normal production location and settings.

[Updated on 8/18/2014 4:35 PM]

unknown

We had over 70 million records also until we used PR300 to purge/archive a few years of data. Our problem is that when the dbreorg is part of the CTP activate step, there is no opportunity to change the default disk location to one that has enough space. We are going to attempt it again by doing a manual dbreorg after the CTP preview/update steps.

unknown

Thank you very much for your replies. Space is not an issue to us, the problem is dbreorg took too long to finish. We can't take our production system down for this long. How many hours did it take to dbreorg your prtime table? Thanks!

moellerg

All: See here. www.lawsonguru.com/.../

You may have to create a free acct first, but well worth it!!

unknown

Thanks Greg. Actually I posted my question there too. Will look into it.

unknown

I am not for sure on all of the steps related the ATM on separating out the steps for the posting the on GURU.

We have 77 mil records. When we applied the MSP that required the PRTIME dump and load it took 6 hours for that table. We knew how long this was going to take so prior to applying in Production we made the database adjustments.

Is this CTP part of the BSI requirement?

unknown

Thanks Roxann. We install this CTP in the hope to fix one program error we have. I am not sure whether this is the same CTP for BSI10 requirement. As shown below is the database changes for PRTIME table from this CTP:

File PRTIME Will be Reorganized.
Index PRTSET12 Added
Field CONTRACT-NBR Added
Field SEGMENT-NBR Added
Field CYC-START-DATE Added
Field CYC-END-DATE Added
Field CM-REG-FLAG Added
Field CM130-FLAG Added
Field MEMO Added

plancor

Hello. I'm not sure if this will help everyone, but....

When I installed the BSI 10 CTP, a few programs did not compile. To fix, Support referred me to a patch that would have done a dbreorg of PRTIME. When I questioned the feasibility of a dbreorg on PRTIME, support then referred me to the following instead...

CTP 100149 KB article 1497552

This one successfully compiled the programs that were previously in error, and did not require a dbreorg on PRTIME.

unknown

Which version of applications are you on?

unknown

Really appreciate the information. We are on application 9.0.1.7. Regarding environment, we are in the process of upgrading to 9.0.1.13.

lbecker

We never let a CTP reorg a table. It's been a long time since I last had to do this, so I'm going by memory.

First, we have the DBA's modify the table with correct SQL statements to add a column, add an index, or whatever.

Second, we make the changes manually in "dbdef", or pull copies of the table changes from the CTP, and load them with metaloadtbl.

Third, run "dbreorg -d" to make the data dictionary happy.

Last, apply the CTP. It sees that no changes were made to the dictionary (because they were already completed). Lawappinstall goes on its merry way.

If using Oracle, you can alway check your work with "verifyora10"

unknown

Jack, thanks so much for sharing this. That's exactly what we plan to do except that we'll only manually take care of PRTIME table, and let lawappinstall take care of the rest database changes, since the rest doesn't take much time to run.

Copyright © 2025 Infor. All rights reserved.