Well almost, but not quit. the bi file contains the before image of all
records that are being changed at any given moment. As a transaction
completes, the bi notes are marked complete, and the space can be
reused. If the data base crashes, on re-start the recovery process goes
through the bi file looking for open bi notes, restores the records to
their initial state and clears the note. Your Data Integrity is
preserved, and the only lost work are the transactions open at the
moment of the crash.
Two things can impact the size of the bi file. Running a process that
produces a very large transaction - a schema update is the classic
example since ALL records in the table must be updated i.e. all records
are open for change - is one case. The second case is the user who
starts a transaction - posting a sales order for example - and going for
lunch leaving the order half completed and on their screen. In this
case, other subsequent transactions have to be written after the notes
for the pending open transaction, and if this stays open for a long
time, and there are a lot of other transactions being processed, this
can lead to considerable, and rapid bi growth. Obviously some
precautions can be taken to protect against this problem - Good design
and code structure are important, (this would have to be implemented by
Epicor and I have no reason to believe that they have not done their
utmost to protect against the problem as much as possible) and user
discipline (Users never leave any screen open unless they are actually
at the machine doing something).
The total number of users has only a very minor impact on bi size. Users
running primarily reports and queries have little impact on the bi file
since any records they examine will be read without locking, and hence
don't get written to the bi file. The number of users doing heavy duty
data entry have an impact, as do large batch update jobs.
HTH.
Troy Funte wrote:
/* ================================================================*/
Specialists in Progress Databases and Software since 1986
William E. Colls william@...
PROComputer Systems Tel 613 591 0079
67 Willow Glen Dr. Fax 613 591 3924
Kanata Ontario Canada www.procomsys.com
K2M 1T1
records that are being changed at any given moment. As a transaction
completes, the bi notes are marked complete, and the space can be
reused. If the data base crashes, on re-start the recovery process goes
through the bi file looking for open bi notes, restores the records to
their initial state and clears the note. Your Data Integrity is
preserved, and the only lost work are the transactions open at the
moment of the crash.
Two things can impact the size of the bi file. Running a process that
produces a very large transaction - a schema update is the classic
example since ALL records in the table must be updated i.e. all records
are open for change - is one case. The second case is the user who
starts a transaction - posting a sales order for example - and going for
lunch leaving the order half completed and on their screen. In this
case, other subsequent transactions have to be written after the notes
for the pending open transaction, and if this stays open for a long
time, and there are a lot of other transactions being processed, this
can lead to considerable, and rapid bi growth. Obviously some
precautions can be taken to protect against this problem - Good design
and code structure are important, (this would have to be implemented by
Epicor and I have no reason to believe that they have not done their
utmost to protect against the problem as much as possible) and user
discipline (Users never leave any screen open unless they are actually
at the machine doing something).
The total number of users has only a very minor impact on bi size. Users
running primarily reports and queries have little impact on the bi file
since any records they examine will be read without locking, and hence
don't get written to the bi file. The number of users doing heavy duty
data entry have an impact, as do large batch update jobs.
HTH.
Troy Funte wrote:
>--
> The BI file stands for Before Image. It is the file that keeps track of everything that is currently OPENED in your progress database - just in case the database or disk crashes. In so doing, you can reconstruct the database using the BI file to restore any records or data that didn't get closed out. Thus, the more users with files open, the larger the BI file will get. And it never shrinks unless you "truncate" it (following Epicor or Progress instructions). After truncating the BI file, it will grow again to a 'normal' size, and as Wayne mentioned it can get quite large while doing schema changes.
>
> Troy Funte
> Liberty Electronics
>
> ----- Original Message -----
> From: Todd Caughey
> To: 'vantage@yahoogroups.com'
> Sent: Monday, November 12, 2001 5:29 PM
> Subject: RE: [Vantage] IMPORTANT - your backups may not be working!
>
> Pardon my ignorance of Progress internals but is the B1 file anything like a
> BTree or Index structure for the data? Could it be that the 5.0 conversion
> is inefficient and causes it to expand? Is there a method for unloading and
> reloading the database or compressing the index structure to make it more
> efficient and has anyone tried this on a post 5.0 converted database to see
> if it makes a difference? Just curious and not knowledgeable enough about
> Progress (but wish I were) to know if this makes any sense at all.
> -Todd C.
>
> -----Original Message-----
> From: Thad Jacobs [mailto:tjacobs@...]
> Sent: Monday, November 12, 2001 4:19 PM
> To: 'vantage@yahoogroups.com'
> Subject: RE: [Vantage] IMPORTANT - your backups may not be working!
>
> >Why is the b1 file so large for V5 ?
>
> the fact that Version 5 has many added fields and tables is my best guess,
> though the differing version of progress could possibly be a factor...
>
> -----Original Message-----
> From: Michael Miles [mailto:mmiles@...]
> Sent: Monday, November 12, 2001 3:49 PM
> To: vantage@yahoogroups.com
> Subject: RE: [Vantage] IMPORTANT - your backups may not be working!
>
> I'm yet to go live with five, but have both on our server for testing
> purposes. On seeing this message I thought I would double-check the
> backup.txt files that is created by VNTGBKUP (in \progress\bin in my case).
>
> The strange thing is that my backup file for V5 is 60MB larger than V4 which
> is odd, because the data on V5 is about 3 weeks older and fairly static.
> Looking in the db folder reveals
>
> V4, d1=399, b1=20, backup.1=420
> V5, d1=387, b1=99, backup.1=486
>
> Why is the b1 file so large for V5 ?
> -----Original Message-----
> From: Wayne Cox [mailto:wmc@...]
> Sent: Tuesday, 13 November 2001 3:20
> To: vantage@yahoogroups.com
> Subject: [Vantage] IMPORTANT - your backups may not be working!
>
> Hi All,
>
> I ran a test conversion from 4 -> 5.0 this weekend. In the process I found
> a glitch in Epicor's BackVan.Bat file that many of you may be using with
> 5.0. It was not updated from 4.0, and the line that specifies the backup
> target path to the Vantage database still reads
> \epicor\vantage\db\vantage Version 5 changed the \epicor directory to
> \epic50. If you still have 4 loaded on your server then the old path is
> still valid; and there is a possibility your backup routine is copying
> your old 4.0 data, not 5's!
>
> If you're on 5, I'd advise checking your backups. Make sure they're
> restorable (always a good exercise) as well as containing your current data.
>
> -Wayne Cox
>
> 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/.
> <http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> <http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/links
> <http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> <http://docs.yahoo.com/info/terms/>
>
> 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/.
> <http://groups.yahoo.com/group/vantage/files/.>
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> <http://groups.yahoo.com/group/vantage/messages>
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/links
> <http://groups.yahoo.com/group/vantage/links>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
> <http://docs.yahoo.com/info/terms/> .
>
> [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/links
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> [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/links
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
/* ================================================================*/
Specialists in Progress Databases and Software since 1986
William E. Colls william@...
PROComputer Systems Tel 613 591 0079
67 Willow Glen Dr. Fax 613 591 3924
Kanata Ontario Canada www.procomsys.com
K2M 1T1