The B1 File Blank Title 73047

No - nothing will truncate it automatically - because it can't be
truncated while the DB is running. Would be fairly easy to do with
scripts.



However:

1) 200k is tiny and should not be worried about - it probably jumps
because you have a large transaction operation running on certain nights
and not others.

2) There is some science performance wise to never truncate the BI
files unless they accidentally get very large (maybe 100MB+, maybe more
depending on the horsepower and size of your server), otherwise each
time the Progress server needs a new BI block it has to allocate it from
the file server, this can be slow down as no transaction for anyone can
continue until the new block is built.



Thank you,



Justin C. Muller

President, Managing Partner

Velocity Development Group, LLC

jmuller@... <mailto:jmuller@...>

www.velocitydev.com <http://www.velocitydev.com>



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of drew.pete
Sent: Tuesday, September 08, 2009 3:08 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: The B1 File





Is it possible to have truncation run automatically if it reaches a
certain size??

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
wayne <wmc20@...> wrote:
>
> Matt Caldwell wrote:
> > What is the B1 file, and what can cause it to jump from 23K to 201K
in
> > size overnight? Been monitoring it for a few months, and it has
> > remained the same size for about 2 months, and then it grows almost
10x
> > in 1 night. Curious.
>
> As others mentioned, it is used to restore records to their original
> state if a transaction is canceled. Once a record lock is released and

> the record updated, the BI space is flagged as reusable. Normally only

> a few records are locked at any time, and it keeps reusing freed space

> and it never grows much.
>
> If you have a poorly written program looping through many records
doing
> updates, it may leave them ALL locked till the entire process
finishes.
> This can make the file grow.
>
> 200K is TINY though. Often it's several megs. Unless you're backing up

> to floppy disks or something don't worry about it.
>
> -Wayne
>





[Non-text portions of this message have been removed]
What is the B1 file, and what can cause it to jump from 23K to 201K in
size overnight? Been monitoring it for a few months, and it has
remained the same size for about 2 months, and then it grows almost 10x
in 1 night. Curious.



Matt Caldwell
Technical Support Analyst

KERUSSO
P.O. Box 32
Berryville, AR 72616
Phone: 800-424-0943 Ext. 231 or 870-480-4530
Fax: 870-423-3568
Web Site: http://www.kerusso.com
******************************************************************
CONFIDENTIALITY STATEMENT:
This message, from Kerusso Inc., contains information
which is privileged and confidential and is solely for the use of
the intended recipient. If you are not the intended recipient, be
aware that any review, disclosure, copying, distribution, or use
of the contents of this message is strictly prohibited. If you have
received this in error, please destroy it and notify us immediately
at: 800-424-0943
******************************************************************





[Non-text portions of this message have been removed]
I was writing up an expanation but when I was done, I could barely
understand it...

So here is an explanation off the web.

"The before-image log, also called the 'bi file', contains the primary
transaction log of the Progress RDBMS. It is an integral and essential part
of every database and is just as important as the data extents used to store
table data and their associated indexes. Without the before-image log
extents, the database cannot be accessed." ... "Although it is called the
'before-image' log, the data stored in it are not before-images of anything.
The name is historical and perhaps was poorly chosen. The before-image log
contains records, called 'notes', that allow previously made changes to the
database to be repeated (redone) or rolled back (undone). The before-image
log is mainly used for two things: to perform crash recovery in the event of
a failure, and to perform transaction rollback during normal processing."

However, given that your b1 file is so small, I am guessing you are on an
SQL DB? If this is the case, then it really doesn't matter or mean that much
how big it is since there is no real data stored in it.

I am guessing overnight you may have run some large process like MRP or
something else which would cause a lot of writes to the DB.


----- Original Message -----
From: "Matt Caldwell" <matt@...>
To: <vantage@yahoogroups.com>
Sent: Friday, January 16, 2009 8:30 AM
Subject: [Vantage] The B1 File


> What is the B1 file, and what can cause it to jump from 23K to 201K in
> size overnight? Been monitoring it for a few months, and it has
> remained the same size for about 2 months, and then it grows almost 10x
> in 1 night. Curious.
>
>
>
> Matt Caldwell
> Technical Support Analyst
>
> KERUSSO
> P.O. Box 32
> Berryville, AR 72616
> Phone: 800-424-0943 Ext. 231 or 870-480-4530
> Fax: 870-423-3568
> Web Site: http://www.kerusso.com
> ******************************************************************
> CONFIDENTIALITY STATEMENT:
> This message, from Kerusso Inc., contains information
> which is privileged and confidential and is solely for the use of
> the intended recipient. If you are not the intended recipient, be
> aware that any review, disclosure, copying, distribution, or use
> of the contents of this message is strictly prohibited. If you have
> received this in error, please destroy it and notify us immediately
> at: 800-424-0943
> ******************************************************************
>
>
>
>
>
> [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
>
>
>
> What is the B1 file, and what can cause it to jump from 23K to 201K in
> size overnight? Been monitoring it for a few months, and it has
> remained the same size for about 2 months, and then it grows almost 10x
> in 1 night. Curious.

The BI file is called the "before image" file. It is used for recovery
purposes. Before a record is modified, a copy is made in this file. If the
transaction fails, the record images are returned to the database. BTW,
there is also an after image file but it is generally not enabled in
Vantage/Epicor installations.

Why does it grow? I have no idea. It REALLY grows during a Schema Change. In
our Epicor 9 upgrade, our BI file got within a few K of the actual database.

There's more information in the Progress tuning guide and at Progress Web
site in the OpenEdge Manager guide.

Mark W.
It was once explained to me by support that the B1 file is kind of like
the garbage file for vantage processes. Meaning that bad process files,
interrupted process files and incomplete process files will get stored
here and will only leave this file when you truncate it. Ours will grow
in excess of 300,000K before I wipe it out. I will do this about every
two weeks. We've noticed a little bit of a performance improvement when
the file is cleaned out.



________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Mark Wonsil
Sent: Friday, January 16, 2009 8:38 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] The B1 File



> What is the B1 file, and what can cause it to jump from 23K to 201K in
> size overnight? Been monitoring it for a few months, and it has
> remained the same size for about 2 months, and then it grows almost
10x
> in 1 night. Curious.

The BI file is called the "before image" file. It is used for recovery
purposes. Before a record is modified, a copy is made in this file. If
the
transaction fails, the record images are returned to the database. BTW,
there is also an after image file but it is generally not enabled in
Vantage/Epicor installations.

Why does it grow? I have no idea. It REALLY grows during a Schema
Change. In
our Epicor 9 upgrade, our BI file got within a few K of the actual
database.

There's more information in the Progress tuning guide and at Progress
Web
site in the OpenEdge Manager guide.

Mark W.





[Non-text portions of this message have been removed]
If you are in a MSSQL environment then you can flush your .b1 file
according to the instructions Epicor provides as part of the procedure to
make your Progress schema holder database Read Only and the file will stay
at 8K forever.

-bws

On 1/16/09 8:37 AM, "Ned" <TechnoBabbly@...> wrote:
>
> However, given that your b1 file is so small, I am guessing you are on an
> SQL DB? If this is the case, then it really doesn't matter or mean that much
> how big it is since there is no real data stored in it.
>
> I am guessing overnight you may have run some large process like MRP or
> something else which would cause a lot of writes to the DB.
>
>
>
>
> .
>
>



[Non-text portions of this message have been removed]
Matt Caldwell wrote:
> What is the B1 file, and what can cause it to jump from 23K to 201K in
> size overnight? Been monitoring it for a few months, and it has
> remained the same size for about 2 months, and then it grows almost 10x
> in 1 night. Curious.

As others mentioned, it is used to restore records to their original
state if a transaction is canceled. Once a record lock is released and
the record updated, the BI space is flagged as reusable. Normally only
a few records are locked at any time, and it keeps reusing freed space
and it never grows much.

If you have a poorly written program looping through many records doing
updates, it may leave them ALL locked till the entire process finishes.
This can make the file grow.

200K is TINY though. Often it's several megs. Unless you're backing up
to floppy disks or something don't worry about it.

-Wayne
> 200K is TINY though. Often it's several megs. Unless you're backing up
> to floppy disks or something don't worry about it.

Wayne makes a good point. The BI file is backed up with the rest of the
database, so if it gets large enough, you may want to truncate it. You also
want to truncate it before making schema changes during upgrades.

To truncate it:

- Stop your appservers and your database

- Open the PROENV program (Start | Programs | OpenEdge 1##.#)

- Use Chdir to navigate to the directory or the database
(Do a DIR to see the .bi size)

- proutil mfgsys -C truncate bi
(and the C MUST be in caps, do another DIR to see the result)

- Start your database and appservers

Mark W.

P.S. I didn't know that the whole record wasn't logged. Learn something
every day...
Good info here guys, thanks. That should have been 200,000K, not 200K.
Anyway, I was told by Epicor to truncate it when the size of it was over
half that of the database files. They are about equal now. Gonna need
to truncate that thing. Got another question, but I'll start a
new post on that.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Mark Wonsil
Sent: Friday, January 16, 2009 8:56 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] The B1 File



> 200K is TINY though. Often it's several megs. Unless you're backing up
> to floppy disks or something don't worry about it.

Wayne makes a good point. The BI file is backed up with the rest of the
database, so if it gets large enough, you may want to truncate it. You
also
want to truncate it before making schema changes during upgrades.

To truncate it:

- Stop your appservers and your database

- Open the PROENV program (Start | Programs | OpenEdge 1##.#)

- Use Chdir to navigate to the directory or the database
(Do a DIR to see the .bi size)

- proutil mfgsys -C truncate bi
(and the C MUST be in caps, do another DIR to see the result)

- Start your database and appservers

Mark W.

P.S. I didn't know that the whole record wasn't logged. Learn something
every day...





[Non-text portions of this message have been removed]
Is it possible to have truncation run automatically if it reaches a certain size??

--- In vantage@yahoogroups.com, wayne <wmc20@...> wrote:
>
> Matt Caldwell wrote:
> > What is the B1 file, and what can cause it to jump from 23K to 201K in
> > size overnight? Been monitoring it for a few months, and it has
> > remained the same size for about 2 months, and then it grows almost 10x
> > in 1 night. Curious.
>
> As others mentioned, it is used to restore records to their original
> state if a transaction is canceled. Once a record lock is released and
> the record updated, the BI space is flagged as reusable. Normally only
> a few records are locked at any time, and it keeps reusing freed space
> and it never grows much.
>
> If you have a poorly written program looping through many records doing
> updates, it may leave them ALL locked till the entire process finishes.
> This can make the file grow.
>
> 200K is TINY though. Often it's several megs. Unless you're backing up
> to floppy disks or something don't worry about it.
>
> -Wayne
>