B1 file growth - request for coments

Yahoo Archive
1
We have found the apparent source of the problem. We made a change to the production calendars in prep for getting scheduling going. The day we made that change is the day we started having this issue. We set all of the calendars to 24 hrs and the issue stopped. Still not sure what's going on in detail but we've found a place to start.

--- In vantage@yahoogroups.com, "cmulford_66" <cmulford_66@...> wrote:
>
> Check the MOM and/or production standards for the Job with issues. I've run across this when the production standard is VERY high. Usually it's been engineered incorrectly with hours per piece instead up fixed hrs. The job then tries to calc a 20,000 piece job that's supposed to take a 2 hour fixed but instead calcs 40,000 hours for the op. If this happens the bi will run away when ending the activity in MES or doing some scheduling. Have you noticed any issues with MES when ending activty?
>
> I have a dashboard that we run daily to watch for jobs with ops of over a 1000 production or setup hours.
>
> --- In vantage@yahoogroups.com, "vantagenook" <jmcloughlin@> wrote:
> >
> > Anybody have additional insight into this? We are having the same problem starting last week. Our DB is about 5GB but our bi file is growing from 0 to 20GB during the course of 2 shifts. I'm having to get up in the middle of the night and back it up and truncate the bi just to keep running the next day. System gets practically unusable later in the day.
> >
> >
> > --- In vantage@yahoogroups.com, Brian Johnson <bjohnson@> wrote:
> > >
> > > Probably a circular reference. Part->Material->Part. Maybe in multiple levels
> > > Assembly1->SubAssembly2->SubAssembly3->Assembly1.
> > >
> > > Brian Johnson -- Epi-Center <http://epi-ctr.com>
> > > Director of Technical Services | direct: 413-531-2859
> > >
> > > On 10/26/2010 01:16 PM, ppipaulz wrote:
> > > >
> > > > We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job
> > > > Details screen and selects a particular job, that's when the growth starts and stops only when the
> > > > database is shut down (which isn't easy since that user's session doesn't want to terminate by the
> > > > normal shut down process). I confirmed the steps in the test database with the same result with
> > > > only my user present.
> > > >
> > > > Thank you for the replies, info and suggestions.
> > > >
> > > > I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare.
> > > > Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>
2
Hey guys, on the progress databases there is a b1 file that sometimes grows out of control and needs to be truncated/shrunk. I've scheduled this on a weekly basis in order to keep this under control and for the most part it works. However sometimes the file will grow enough to stop the database (when there is no more disk space avaiable due to the b1 file taking it all) between the scheduled truncation and causes us problems. From memory I don't ever recall this happening when we were on Progress 9 on Vantage 6, but now on Progress 10.1b and Vantage 8.3.406a this is a regular occurance for us.

I'm wondering how often those of you who know what I'm talking about (I'm guessing most of you don't even have or are aware of this happening) experience this issue and if you've found any sort of pattern or trigger. If you could post your Vantage and Progress version that would help also.

thank you
3
How big is big and how small is normal?




________________________________
From: ppipaulz <chaosavy@...>
To: vantage@yahoogroups.com
Sent: Tue, 26 October, 2010 15:38:17
Subject: [Vantage] B1 file growth - request for coments

Â
Hey guys, on the progress databases there is a b1 file that sometimes grows out
of control and needs to be truncated/shrunk. I've scheduled this on a weekly
basis in order to keep this under control and for the most part it works.
However sometimes the file will grow enough to stop the database (when there is
no more disk space avaiable due to the b1 file taking it all) between the
scheduled truncation and causes us problems. From memory I don't ever recall
this happening when we were on Progress 9 on Vantage 6, but now on Progress
10.1b and Vantage 8.3.406a this is a regular occurance for us.

I'm wondering how often those of you who know what I'm talking about (I'm
guessing most of you don't even have or are aware of this happening) experience
this issue and if you've found any sort of pattern or trigger. If you could post
your Vantage and Progress version that would help also.

thank you







[Non-text portions of this message have been removed]
4
Also, how big is your actual DB? How many concurrent users do you average?

On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson <chriselectrix@...>wrote:

>
>
> How big is big and how small is normal?
>
> ________________________________
> From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> To: vantage@yahoogroups.com <vantage%40yahoogroups.com>
> Sent: Tue, 26 October, 2010 15:38:17
> Subject: [Vantage] B1 file growth - request for coments
>
>
>
> Hey guys, on the progress databases there is a b1 file that sometimes grows
> out
> of control and needs to be truncated/shrunk. I've scheduled this on a
> weekly
> basis in order to keep this under control and for the most part it works.
> However sometimes the file will grow enough to stop the database (when
> there is
> no more disk space avaiable due to the b1 file taking it all) between the
> scheduled truncation and causes us problems. From memory I don't ever
> recall
> this happening when we were on Progress 9 on Vantage 6, but now on Progress
>
> 10.1b and Vantage 8.3.406a this is a regular occurance for us.
>
> I'm wondering how often those of you who know what I'm talking about (I'm
> guessing most of you don't even have or are aware of this happening)
> experience
> this issue and if you've found any sort of pattern or trigger. If you could
> post
> your Vantage and Progress version that would help also.
>
> thank you
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]
5
The db is 6.06gb. Last Friday and yesterday the b1 file grew to over 24gb then the server ran out of space.

I'm used to seeing the b1 file to be 1 to 2gb in size over the course of a week. I would guess about 40 to a 70 users.

--- In vantage@yahoogroups.com, Waffqle Driggers <waffqle@...> wrote:
>
> Also, how big is your actual DB? How many concurrent users do you average?
>
> On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson <chriselectrix@...>wrote:
>
> >
> >
> > How big is big and how small is normal?
> >
> > ________________________________
> > From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> > To: vantage@yahoogroups.com <vantage%40yahoogroups.com>
> > Sent: Tue, 26 October, 2010 15:38:17
> > Subject: [Vantage] B1 file growth - request for coments
> >
> >
> >
> > Hey guys, on the progress databases there is a b1 file that sometimes grows
> > out
> > of control and needs to be truncated/shrunk. I've scheduled this on a
> > weekly
> > basis in order to keep this under control and for the most part it works.
> > However sometimes the file will grow enough to stop the database (when
> > there is
> > no more disk space avaiable due to the b1 file taking it all) between the
> > scheduled truncation and causes us problems. From memory I don't ever
> > recall
> > this happening when we were on Progress 9 on Vantage 6, but now on Progress
> >
> > 10.1b and Vantage 8.3.406a this is a regular occurance for us.
> >
> > I'm wondering how often those of you who know what I'm talking about (I'm
> > guessing most of you don't even have or are aware of this happening)
> > experience
> > this issue and if you've found any sort of pattern or trigger. If you could
> > post
> > your Vantage and Progress version that would help also.
> >
> > thank you
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
6
Whoa, something is definitely wrong. Hate to sound like a broken record
but I would perform a Dump & Load of the database.



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of ppipaulz
Sent: Tuesday, October 26, 2010 11:27 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: B1 file growth - request for coments





The db is 6.06gb. Last Friday and yesterday the b1 file grew to over
24gb then the server ran out of space.

I'm used to seeing the b1 file to be 1 to 2gb in size over the course of
a week. I would guess about 40 to a 70 users.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Waffqle Driggers <waffqle@...> wrote:
>
> Also, how big is your actual DB? How many concurrent users do you
average?
>
> On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson
<chriselectrix@...>wrote:
>
> >
> >
> > How big is big and how small is normal?
> >
> > ________________________________
> > From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<vantage%40yahoogroups.com>
> > Sent: Tue, 26 October, 2010 15:38:17
> > Subject: [Vantage] B1 file growth - request for coments
> >
> >
> >
> > Hey guys, on the progress databases there is a b1 file that
sometimes grows
> > out
> > of control and needs to be truncated/shrunk. I've scheduled this on
a
> > weekly
> > basis in order to keep this under control and for the most part it
works.
> > However sometimes the file will grow enough to stop the database
(when
> > there is
> > no more disk space avaiable due to the b1 file taking it all)
between the
> > scheduled truncation and causes us problems. From memory I don't
ever
> > recall
> > this happening when we were on Progress 9 on Vantage 6, but now on
Progress
> >
> > 10.1b and Vantage 8.3.406a this is a regular occurance for us.
> >
> > I'm wondering how often those of you who know what I'm talking about
(I'm
> > guessing most of you don't even have or are aware of this happening)
> > experience
> > this issue and if you've found any sort of pattern or trigger. If
you could
> > post
> > your Vantage and Progress version that would help also.
> >
> > thank you
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>





[Non-text portions of this message have been removed]
7
Our system starts getting sluggish at 8gb so your file is massive.




________________________________
From: Blake Clemens <blake.clemens@...>
To: vantage@yahoogroups.com
Sent: Tue, 26 October, 2010 16:30:03
Subject: RE: [Vantage] Re: B1 file growth - request for coments

Â
Whoa, something is definitely wrong. Hate to sound like a broken record
but I would perform a Dump & Load of the database.

Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of ppipaulz
Sent: Tuesday, October 26, 2010 11:27 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: B1 file growth - request for coments

The db is 6.06gb. Last Friday and yesterday the b1 file grew to over
24gb then the server ran out of space.

I'm used to seeing the b1 file to be 1 to 2gb in size over the course of
a week. I would guess about 40 to a 70 users.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Waffqle Driggers <waffqle@...> wrote:
>
> Also, how big is your actual DB? How many concurrent users do you
average?
>
> On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson
<chriselectrix@...>wrote:
>
> >
> >
> > How big is big and how small is normal?
> >
> > ________________________________
> > From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<vantage%40yahoogroups.com>
> > Sent: Tue, 26 October, 2010 15:38:17
> > Subject: [Vantage] B1 file growth - request for coments
> >
> >
> >
> > Hey guys, on the progress databases there is a b1 file that
sometimes grows
> > out
> > of control and needs to be truncated/shrunk. I've scheduled this on
a
> > weekly
> > basis in order to keep this under control and for the most part it
works.
> > However sometimes the file will grow enough to stop the database
(when
> > there is
> > no more disk space avaiable due to the b1 file taking it all)
between the
> > scheduled truncation and causes us problems. From memory I don't
ever
> > recall
> > this happening when we were on Progress 9 on Vantage 6, but now on
Progress
> >
> > 10.1b and Vantage 8.3.406a this is a regular occurance for us.
> >
> > I'm wondering how often those of you who know what I'm talking about
(I'm
> > guessing most of you don't even have or are aware of this happening)
> > experience
> > this issue and if you've found any sort of pattern or trigger. If
you could
> > post
> > your Vantage and Progress version that would help also.
> >
> > thank you
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]
8
We have a 20 GB database and our B1 file never gets over 2 GB.



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Chris Thompson
Sent: Tuesday, October 26, 2010 11:36 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: B1 file growth - request for coments





Our system starts getting sluggish at 8gb so your file is massive.

________________________________
From: Blake Clemens <blake.clemens@... <mailto:blake.clemens%40d-m-c.com> >
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Sent: Tue, 26 October, 2010 16:30:03
Subject: RE: [Vantage] Re: B1 file growth - request for coments


Whoa, something is definitely wrong. Hate to sound like a broken record
but I would perform a Dump & Load of the database.

Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On Behalf
Of ppipaulz
Sent: Tuesday, October 26, 2010 11:27 AM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Re: B1 file growth - request for coments

The db is 6.06gb. Last Friday and yesterday the b1 file grew to over
24gb then the server ran out of space.

I'm used to seeing the b1 file to be 1 to 2gb in size over the course of
a week. I would guess about 40 to a 70 users.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> <mailto:vantage%40yahoogroups.com> ,
Waffqle Driggers <waffqle@...> wrote:
>
> Also, how big is your actual DB? How many concurrent users do you
average?
>
> On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson
<chriselectrix@...>wrote:
>
> >
> >
> > How big is big and how small is normal?
> >
> > ________________________________
> > From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> <mailto:vantage%40yahoogroups.com>
<vantage%40yahoogroups.com>
> > Sent: Tue, 26 October, 2010 15:38:17
> > Subject: [Vantage] B1 file growth - request for coments
> >
> >
> >
> > Hey guys, on the progress databases there is a b1 file that
sometimes grows
> > out
> > of control and needs to be truncated/shrunk. I've scheduled this on
a
> > weekly
> > basis in order to keep this under control and for the most part it
works.
> > However sometimes the file will grow enough to stop the database
(when
> > there is
> > no more disk space avaiable due to the b1 file taking it all)
between the
> > scheduled truncation and causes us problems. From memory I don't
ever
> > recall
> > this happening when we were on Progress 9 on Vantage 6, but now on
Progress
> >
> > 10.1b and Vantage 8.3.406a this is a regular occurance for us.
> >
> > I'm wondering how often those of you who know what I'm talking about
(I'm
> > guessing most of you don't even have or are aware of this happening)
> > experience
> > this issue and if you've found any sort of pattern or trigger. If
you could
> > post
> > your Vantage and Progress version that would help also.
> >
> > thank you
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
9
A dump and load would likely help. But if your B1 is getting that large, I
would think there is almost certainly a larger issue at hand.

Unfortunately I can't think of anything off hand that would cause it to get
that large.

Do you have automated processes? If your transaction volume was through the
roof, that might do it. But I'd think your server would choke before you
could get enough transactions to get the b1 that large.

Do you have any custom code or outside apps that access the Epicor database?
If you have transactions that are left hanging (waiting for input or
something) that can cause growth.


On Tue, Oct 26, 2010 at 11:38 AM, Blake Clemens <blake.clemens@...>wrote:

>
>
> We have a 20 GB database and our B1 file never gets over 2 GB.
>
>
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups.com <vantage%40yahoogroups.com> [mailto:
> vantage@yahoogroups.com <vantage%40yahoogroups.com>] On Behalf Of Chris
> Thompson
> Sent: Tuesday, October 26, 2010 11:36 AM
> To: vantage@yahoogroups.com <vantage%40yahoogroups.com>
> Subject: Re: [Vantage] Re: B1 file growth - request for coments
>
>
>
>
>
> Our system starts getting sluggish at 8gb so your file is massive.
>
> ________________________________
> From: Blake Clemens <blake.clemens@... <blake.clemens%40d-m-c.com><mailto:
> blake.clemens%40d-m-c.com <blake.clemens%2540d-m-c.com>> >
> To: vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>>
> Sent: Tue, 26 October, 2010 16:30:03
> Subject: RE: [Vantage] Re: B1 file growth - request for coments
>
>
> Whoa, something is definitely wrong. Hate to sound like a broken record
> but I would perform a Dump & Load of the database.
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>> [mailto:
> vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>> ] On Behalf
> Of ppipaulz
> Sent: Tuesday, October 26, 2010 11:27 AM
> To: vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>>
> Subject: [Vantage] Re: B1 file growth - request for coments
>
> The db is 6.06gb. Last Friday and yesterday the b1 file grew to over
> 24gb then the server ran out of space.
>
> I'm used to seeing the b1 file to be 1 to 2gb in size over the course of
> a week. I would guess about 40 to a 70 users.
>
> --- In vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>> ,
> Waffqle Driggers <waffqle@...> wrote:
> >
> > Also, how big is your actual DB? How many concurrent users do you
> average?
> >
> > On Tue, Oct 26, 2010 at 10:51 AM, Chris Thompson
> <chriselectrix@...>wrote:
> >
> > >
> > >
> > > How big is big and how small is normal?
> > >
> > > ________________________________
> > > From: ppipaulz <chaosavy@... <chaosavy%40ymail.com>>
> > > To: vantage@yahoogroups.com <vantage%40yahoogroups.com> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>> <mailto:
> vantage%40yahoogroups.com <vantage%2540yahoogroups.com>>
> <vantage%40yahoogroups.com>
> > > Sent: Tue, 26 October, 2010 15:38:17
> > > Subject: [Vantage] B1 file growth - request for coments
> > >
> > >
> > >
> > > Hey guys, on the progress databases there is a b1 file that
> sometimes grows
> > > out
> > > of control and needs to be truncated/shrunk. I've scheduled this on
> a
> > > weekly
> > > basis in order to keep this under control and for the most part it
> works.
> > > However sometimes the file will grow enough to stop the database
> (when
> > > there is
> > > no more disk space avaiable due to the b1 file taking it all)
> between the
> > > scheduled truncation and causes us problems. From memory I don't
> ever
> > > recall
> > > this happening when we were on Progress 9 on Vantage 6, but now on
> Progress
> > >
> > > 10.1b and Vantage 8.3.406a this is a regular occurance for us.
> > >
> > > I'm wondering how often those of you who know what I'm talking about
> (I'm
> > > guessing most of you don't even have or are aware of this happening)
> > > experience
> > > this issue and if you've found any sort of pattern or trigger. If
> you could
> > > post
> > > your Vantage and Progress version that would help also.
> > >
> > > thank you
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]
10
We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job Details screen and selects a particular job, that's when the growth starts and stops only when the database is shut down (which isn't easy since that user's session doesn't want to terminate by the normal shut down process). I confirmed the steps in the test database with the same result with only my user present.

Thank you for the replies, info and suggestions.

I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare. Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
11
> We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job Details screen and selects a particular job, that's when the growth starts and stops only when the database is shut down (which isn't easy since that user's session doesn't want to terminate by the normal shut down process). I confirmed the steps in the test database with the same result with only my user present.
>
> Thank you for the replies, info and suggestions.
>
> I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare. Next steps are to figure out why this is happening with this particular job, and somehow prevent it.

Just out of curiosity, was this job engineered by the Product Configurator?

Mark W.
12
Nope, I don't think we use the product configurator at all.

--- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@...> wrote:
>
> > We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job Details screen and selects a particular job, that's when the growth starts and stops only when the database is shut down (which isn't easy since that user's session doesn't want to terminate by the normal shut down process). I confirmed the steps in the test database with the same result with only my user present.
> >
> > Thank you for the replies, info and suggestions.
> >
> > I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare. Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
>
> Just out of curiosity, was this job engineered by the Product Configurator?
>
> Mark W.
>
13
Probably a circular reference. Part->Material->Part. Maybe in multiple levels
Assembly1->SubAssembly2->SubAssembly3->Assembly1.

Brian Johnson -- Epi-Center <http://epi-ctr.com>
Director of Technical Services | direct: 413-531-2859

On 10/26/2010 01:16 PM, ppipaulz wrote:
>
> We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job
> Details screen and selects a particular job, that's when the growth starts and stops only when the
> database is shut down (which isn't easy since that user's session doesn't want to terminate by the
> normal shut down process). I confirmed the steps in the test database with the same result with
> only my user present.
>
> Thank you for the replies, info and suggestions.
>
> I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare.
> Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
>
>


[Non-text portions of this message have been removed]
14
Anybody have additional insight into this? We are having the same problem starting last week. Our DB is about 5GB but our bi file is growing from 0 to 20GB during the course of 2 shifts. I'm having to get up in the middle of the night and back it up and truncate the bi just to keep running the next day. System gets practically unusable later in the day.


--- In vantage@yahoogroups.com, Brian Johnson <bjohnson@...> wrote:
>
> Probably a circular reference. Part->Material->Part. Maybe in multiple levels
> Assembly1->SubAssembly2->SubAssembly3->Assembly1.
>
> Brian Johnson -- Epi-Center <http://epi-ctr.com>
> Director of Technical Services | direct: 413-531-2859
>
> On 10/26/2010 01:16 PM, ppipaulz wrote:
> >
> > We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job
> > Details screen and selects a particular job, that's when the growth starts and stops only when the
> > database is shut down (which isn't easy since that user's session doesn't want to terminate by the
> > normal shut down process). I confirmed the steps in the test database with the same result with
> > only my user present.
> >
> > Thank you for the replies, info and suggestions.
> >
> > I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare.
> > Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
15
You likely have a bad BAQ or BPM running. I would stop all BPM's and
slowly restart all of them to see where the problem lies. Bad BAQ's are
known to make the bi file large as well.

Travis Late
Divisional IT Manager
+1 619 216 2217 Office
+1 920 960 0062 Mobile
tlate@...

Doncasters GCE Industries, Inc.
1891 Nivana Avenue, Chula Vista, CA 91911





From: "vantagenook" <jmcloughlin@...>
To: vantage@yahoogroups.com
Date: 08/26/2011 05:40 AM
Subject: [Vantage] Re: B1 file growth - request for coments
Sent by: vantage@yahoogroups.com




Anybody have additional insight into this? We are having the same problem
starting last week. Our DB is about 5GB but our bi file is growing from 0
to 20GB during the course of 2 shifts. I'm having to get up in the middle
of the night and back it up and truncate the bi just to keep running the
next day. System gets practically unusable later in the day.

--- In vantage@yahoogroups.com, Brian Johnson <bjohnson@...> wrote:
>
> Probably a circular reference. Part->Material->Part. Maybe in multiple
levels
> Assembly1->SubAssembly2->SubAssembly3->Assembly1.
>
> Brian Johnson -- Epi-Center <http://epi-ctr.com>
> Director of Technical Services | direct: 413-531-2859
>
> On 10/26/2010 01:16 PM, ppipaulz wrote:
> >
> > We've found the source of the growth, when a user in the Job Entry
screen goes to the Get Job
> > Details screen and selects a particular job, that's when the growth
starts and stops only when the
> > database is shut down (which isn't easy since that user's session
doesn't want to terminate by the
> > normal shut down process). I confirmed the steps in the test database
with the same result with
> > only my user present.
> >
> > Thank you for the replies, info and suggestions.
> >
> > I think I'm pretty lucky that the user reported the issue, this could
have been ahuge nightmare.
> > Next steps are to figure out why this is happening with this
particular job, and somehow prevent it.
> >
> >
>
>
> [Non-text portions of this message have been removed]
>




************************************************************************

This e-mail is sent on behalf of Doncasters. Its contents are confidential to the recipient and may be legally privileged.

If you are not the intended recipient:

(1) You must not disclose, copy or distribute its contents to any other person nor use its contents in any way;

(2) Please contact Doncasters IT on +44 (0) 1332 694143 quoting the name and sender and the addressee then delete it from your system.

For general enquiries please contact +44 (0) 1332 864900

Doncasters has scanned this e-mail for viruses but does not accept any responsibility for viruses once this e-mail has been transmitted. You should scan attachments (if any) for viruses.

************************************************************************

Doncasters Limited, registered in England no. 321992 at Millennium Court, First Avenue, Burton-upon-Trent, Staffordshire, DE14 2WH, UK


[Non-text portions of this message have been removed]
16
Check the MOM and/or production standards for the Job with issues. I've run across this when the production standard is VERY high. Usually it's been engineered incorrectly with hours per piece instead up fixed hrs. The job then tries to calc a 20,000 piece job that's supposed to take a 2 hour fixed but instead calcs 40,000 hours for the op. If this happens the bi will run away when ending the activity in MES or doing some scheduling. Have you noticed any issues with MES when ending activty?

I have a dashboard that we run daily to watch for jobs with ops of over a 1000 production or setup hours.

--- In vantage@yahoogroups.com, "vantagenook" <jmcloughlin@...> wrote:
>
> Anybody have additional insight into this? We are having the same problem starting last week. Our DB is about 5GB but our bi file is growing from 0 to 20GB during the course of 2 shifts. I'm having to get up in the middle of the night and back it up and truncate the bi just to keep running the next day. System gets practically unusable later in the day.
>
>
> --- In vantage@yahoogroups.com, Brian Johnson <bjohnson@> wrote:
> >
> > Probably a circular reference. Part->Material->Part. Maybe in multiple levels
> > Assembly1->SubAssembly2->SubAssembly3->Assembly1.
> >
> > Brian Johnson -- Epi-Center <http://epi-ctr.com>
> > Director of Technical Services | direct: 413-531-2859
> >
> > On 10/26/2010 01:16 PM, ppipaulz wrote:
> > >
> > > We've found the source of the growth, when a user in the Job Entry screen goes to the Get Job
> > > Details screen and selects a particular job, that's when the growth starts and stops only when the
> > > database is shut down (which isn't easy since that user's session doesn't want to terminate by the
> > > normal shut down process). I confirmed the steps in the test database with the same result with
> > > only my user present.
> > >
> > > Thank you for the replies, info and suggestions.
> > >
> > > I think I'm pretty lucky that the user reported the issue, this could have been ahuge nightmare.
> > > Next steps are to figure out why this is happening with this particular job, and somehow prevent it.
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>