Safe way to shrink or truncate the .b1 file in Epicor Progress DB

Our .b1 file recently grew HUGE due to a database corruption. Everything recovered but our .b1 file went from around 1GB to almost 7GB during the recover process. Our whole database is only 7GB so this is a problem. Was wanting to know a “safe” or “best practice” method for shrinking the .b1 file back down to where it was. Is this possible???

There are two basic ways to reduce the size of a before image file. Offline backup and restore or using the truncate bi command from the PROENV.

Safest I would say would be the offline backup and restore as you also have the added bonus of having a database backup.

  1. Stop your appserver processes and database in the OpenEdge Explorer.
  2. Backup your database.
  3. Restore the backup that you just took over your existing database. When prompted to overwrite, choose Yes.

To be extra paranoid, after you stop your appserver process and database in OpenEdge you can make a copy of the database folder, I usually name the folder like (YYYYMMDDBKUP).

If all goes well you can come back and clean that up later. If things don’t go well and let’s say for some reason your restore (overwrite) doesn’t go well you have a copy of all the files as they were before you started.

Neil

1 Like

:star2:
excellent addition for the level 7 paranoid among us :slight_smile:

Nathan, I’m confused on what you are calling an “offline” backup??? We do an automated backup of the live DB every night but it doesn’t take the db down while it’s doing it. How is this “offline” backup accomplished? Can you take me through the steps?? I’ve “restored” our normal nightly backup many times to our “test” database on the server and I’m very familiar with doing that but the .bi file that gets restored is always the same size it was when it was backed up. Are you saying I can “delete” the .b1 file after the backup? Sorry for all the questions but I want to make sure we do this right.

Best regards

Mike Abell
IT Manager

Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA

Phone: +1 931 432 8408
Fax: +1 931 432 1889
Mail: mabell@flexial.com
Website: http://www.flexial.comhttp://www.flexial.com/
http://www.boagroup.comhttp://www.boagroup.com/

Progress allows for online and offline backups.

  1. Online is where the appservers and database can remain running (but, it also backs up the before image file contents as they are at the moment of backup)
    probkup online [db_name] [backup_name]

  2. Offline is where the appservers and database must be stopped (and it completes the same high-level operations as a truncate BI does before the backup file is created )
    probkup [db_name] [backup_name]

Offline backup time is approximately online backup time + what it would take to complete a truncation of the before image file via PROENV.

1 Like

Offline - when the database and appservers are stopped
e.g. probkup mfgsys xxxxx.bak

vs. OnLine when the database is running
e.g. probkup online mfgsys xxxxx.bak

So, when I restore the “offline” backup, will the .b1 file that was originally there pre-backup just magically go away or shrink itself or do I need to do something with it before I restore?

BTW, I REALLY appreciate this information…

Not that anyone cares, but I use the online backups on my nightly and weekend backups but I use the offline backups for my month end and yearly backups which I keep around much longer. (Level 8 paranoid master).

Bruce, thanks for the info. Makes perfect sense…

Mike…

When an offline backup is restored, the b1 file will magically be set to whatever the last defined initial size was. I believe by default it’s something like <2MB, but, the initial size can be changed from the PROENV through the various bi commands.

Nathan, thanks so much that sounds EXACTLY what I need.

Best regards

Mike Abell
IT Manager

Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA

Phone: +1 931 432 8408
Fax: +1 931 432 1889
Mail: mabell@flexial.com
Website: http://www.flexial.comhttp://www.flexial.com/
http://www.boagroup.comhttp://www.boagroup.com/

I’ve done the truncate bi a couple of times on our E9 environment without any issues. I always create a backup first though. Any reason why the preferred method is to do a full backup and restore?

Some people experience crashes of the PROENV when they attempt to issue a truncate command even with an elevated session, but, when an offline backup is taken it doesn’t; the recommendation is simply based on avoiding that rare condition. The key is to simply make sure to have a recent backup before doing any BI/Dx file changes in case things go pear shaped.

1 Like

That’s kind of what I thought. I just wanted to make sure what I was doing isn’t having adverse effects i don’t know about.

Nathan says:

The key is to simply make sure to have a recent backup before doing any … changes in case things go pear shaped.

You mean I should have made a backup of myself in my 20s?

Now you tell me…

1 Like

huge bi files
I tend to be extra careful…go thru more steps than probably needed.

1.) online backup… probkup online mfgsys xxxxxA.bak
2.) stop appservers/database
3.) truncate:… proutil mfgsys -C truncate bi
4.) offline backup:… probkup mfgsys xxxxxB.bak
5.) restart database/appservers

The online backup and truncate steps can take a long time… depending on the size of the bi file
Also, at some point the size of a bi file can be an issue if run online backups during business hours. Can effect performance for all users. At one site I scheduled a batch file to check bi file size & email me if it gets over a certain size.