Thanks for the clarification. It's pretty much what I was thinking but you described it a lot better. I have still never seen the bi file size go down without truncating but then I don't pay a lot of attention to it unless something odd happens like the time closing a job ran all weekend and the bi growth entirely consumed the hard drive free space. In normal circumstances the space gets re-used over and over but when needed new space is added and the file size grows.
-Todd C.
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ned
Sent: Friday, June 05, 2009 9:29 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: Database growing, table size
You are slightly wrong on your understanding of the BI file.
The BI file is just a transaction log, it holds the contents of a record
before the new information is written. It is not a storage location for
uncommmited transactions.
Example... - is between fields for 1 record.
27 - Tom Jones - Singer - Ballads - British
but then you update it to the correct information
27 - Tom Jones - Singer - R&B/Pop - Welsh
Prior to making those changes, Progress will copy the original record(27 -
Tom Jones - Singer - Ballads - British) to the BI file, and then make the
write of the new record(27 - Tom Jones - Singer - R&B/Pop - Welsh) to the
DB.
As far as the size goes, that depends on the size of the individual records
which are being changed or altered, some records are smaller than others, so
the size of the BI will change.
Truncating the BI file doesn't actually improve or affect the performance of
your DB, for all intents and purposes, it's the equivelant of a flat file
that is only actually used if you want to roll-back your database on a
transactional level. The only reasons to truncate your BI file is to reduce
the size of backups, or to speed up a conversion on an upgrade of OpenEdge.
While your BI file may grow, it will also shrink on it's own. It is a
segmented file. For the sake of example we will say it has 4 segements. It
will write to segment 1, then segment 2, then segment 3, then segment 4,
once it reaches segment 4, it will then overwrite segment 1.
I can try to dig up my OE admin manual this weekend if you want a better
description that file.
-Todd C.
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ned
Sent: Friday, June 05, 2009 9:29 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: Database growing, table size
You are slightly wrong on your understanding of the BI file.
The BI file is just a transaction log, it holds the contents of a record
before the new information is written. It is not a storage location for
uncommmited transactions.
Example... - is between fields for 1 record.
27 - Tom Jones - Singer - Ballads - British
but then you update it to the correct information
27 - Tom Jones - Singer - R&B/Pop - Welsh
Prior to making those changes, Progress will copy the original record(27 -
Tom Jones - Singer - Ballads - British) to the BI file, and then make the
write of the new record(27 - Tom Jones - Singer - R&B/Pop - Welsh) to the
DB.
As far as the size goes, that depends on the size of the individual records
which are being changed or altered, some records are smaller than others, so
the size of the BI will change.
Truncating the BI file doesn't actually improve or affect the performance of
your DB, for all intents and purposes, it's the equivelant of a flat file
that is only actually used if you want to roll-back your database on a
transactional level. The only reasons to truncate your BI file is to reduce
the size of backups, or to speed up a conversion on an upgrade of OpenEdge.
While your BI file may grow, it will also shrink on it's own. It is a
segmented file. For the sake of example we will say it has 4 segements. It
will write to segment 1, then segment 2, then segment 3, then segment 4,
once it reaches segment 4, it will then overwrite segment 1.
I can try to dig up my OE admin manual this weekend if you want a better
description that file.
----- Original Message -----
From: "Todd Caughey" <caugheyt@...<mailto:caugheyt%40harveyvogel.com>>
To: <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
Sent: Friday, June 05, 2009 9:07 AM
Subject: RE: [Vantage] Re: Database growing, table size
> My understanding of the bi file is that it is for the "before images" on
> record changes. Implying that there had to have been something there
> prior to the change so net db file size would not change. It is a safety
> measure for rolling back transactions that were not committed. It grows
> as needed when there are lots of uncommitted transactions in a series of
> events. MRP can create a lot of these. Once committed in the main db the
> images are no longer needed. It will grow as needed but never shrink
> unless "truncated". When the database is stopped, and all transactions
> are committed for sure, then it is just a big empty vessel for future
> before images. In most cases it will grow to the size routine transaction
> sets require and stop growing unless some unusual processing happens, such
> as perhaps year-end activities or mass updates. Then an occasional
> truncate will give back some disk space and let it re-grow to a new normal
> size for the environment.
>
> Which has caused me to have a thought about Service Connect. Because it
> allows a route for importing and mass updating does it have an added
> impact on the need for before images? Just curious how it "plays" with
> the Progress transaction processing and commit actions. Can Service
> Connect bloat the bi file? Just curious.
>
> -Todd C.
>
>
> ________________________________
> From: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com> [mailto:vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>] On Behalf
> Of Blake Clemens
> Sent: Friday, June 05, 2009 7:46 AM
> To: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>
> Subject: RE: [Vantage] Re: Database growing, table size
>
>
>
>
> When I truncate my bi file my db file does not grow in size.
>
> Thanks,
>
> Blake Clemens
>
> DMC
>
> ________________________________
>
> From: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com><mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com><mailto:vantage%40yahoogroups.com>] On
> Behalf
> Of Paul
> Sent: Friday, June 05, 2009 8:44 AM
> To: vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com><mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Re: Database growing, table size
>
>> Maybe this is your issue?
>>
>>
>>
>> Answer:
>>
>> It is not huge yet we have only been using V8 for 5 months and the
> SPEED
>> OF THE GROWTH concerns us.
>>
>> Our Network Tech comments:
>>
>> The bi file is almost the same size as the db itself (400meg) but my
>> experience with truncating the bi file is that it basically just posts
>> transactions to the db making the db larger with an end result of
> using
>> up about the same amount of space as the two files combined. I can't
> do
>> a truncate without taking down the server, if it rains this weekend
>> I'll come in and do it.
>>
>>
>
> From my experience this is not so, my b1 file grew to over 10 gb (my d1
> file is a bit less then 5 gb). When I did the truncate the b1 file went
> down to a low number, and the d1 file stayed at its current number
> (didn't visibly increase).
>
> Maybe with a different erp/application the b1 file behaves as you
> stated, but I don't think this is the case with Vantage. I'm sure some
> more progress oriented person could explain it better.
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
[Non-text portions of this message have been removed]