How to truncate BI files is a target database (OpenEdge Repplication)? - Forum - OpenEdge General - Progress Community

How to truncate BI files is a target database (OpenEdge Repplication)?

 Forum

How to truncate BI files is a target database (OpenEdge Repplication)?

  • Is it possible to  truncate the BI files in a target database.

    Best regards.

  • You cannot.

    Table 5-17 in the OpenEdge Replication User Guide lists the various utility options that are allowed (or disallowed).

    Just curious but why would you want to truncate the bi file on a target?

    --
    Tom Bascom
    tom@wss.com

  • Becouse the size of the BI file it is 1,5 GB and the database takes to start more then 50 minutes.

  • Is the source db also suffering from this?  Or just the target?

    --
    Tom Bascom
    tom@wss.com

  • Only in the target database, in source database i make a truncate bi without problems.

  • Well sure, truncate bi is permitted for the source so that wouldn't be a problem.  What I meant was do you need to?  Does the same problem with a 1.5GB bi file and a 50 minute db start occur on your source db?  (Before you truncate the bi file.)  Or does it only ever happen on the target?

    Do you have a BIW and any APWs running on the target?

    What version of Progress?

    What OS platform?

    --
    Tom Bascom
    tom@wss.com

  • Hi,

    In source database if bi size is 1,5 gb it takes to start 50 minutes, but I make a trucante and it solves the problem.

    In target database only has BIW.

    OpenEdge 10.1B version and Windows Server 2003 R2 Enterprise x64 OS.

    Best Regards

  • I don't have a solution, just some thoughts and questions.

    50 minutes is a long time.  I wonder how the disk subsystem is configured?  I'm guessing either RAID5 or a single large disk.

    What is your bi cluster size?

    If you go through this 50 minute startup and then cleanly shutdown does it also take 50 minutes the next time?

    Why are you stopping and starting the target?  (Not that it is bad to do so, I'm just curious.)

    What happened that caused the original 1.5GB bi file?

    --
    Tom Bascom
    tom@wss.com

  • He's running 10.1B, which means he could be experiencing the long-redo problem.

  • That may be.  Or it might just be a one-time blow out of the bi file.  I can't tell from what we see so far.

    --
    Tom Bascom
    tom@wss.com

  • Hi Tom, about yours questions

    How the disk subsystem is configured?  RAID1 - Mirror.

    What is your bi cluster size? 8 KB

    If you go through this 50 minute startup and then cleanly shutdown does it also take 50 minutes the next time? Yes, every time that I restart the database.

    Why are you stopping and starting the target?  Every night restart the server for "clean" the memory of the server.

    What happened that caused the original 1.5GB bi file? I don't konw.

    Best regards

  • Ok.  My thoughts:

    1) You might want to double-check with tech support but I think you are going to have to re-start replication from scratch in order to eliminate the long target startup time problem.

    2) Are you saying that the entire server has just one mirrored pair of disks?  That isn't going to be a very good for performance under load.  You might want to review the hardware configuration in more detail.

    3) I'm not sure why you feel that you need to shutdown and restart the target every night.  You really shouldn't need to be doing that.  Is it just an administrative habit?  Or is there an observable problem related to the replicated database that is solved by this process?

    4) I would start an APW along with the BIW.

    5) I would add some monitoring to the source database to make sure that long open transactions are noted and dealt with promptly in order to avoid radical bi growth.

    6) If it is not already make sure that the bi file is configured with a large fixed extent, probably at least 2GB (plus a variable extent that should never be used).

    --
    Tom Bascom
    tom@wss.com

  • OK, thanks for all