Autogrowth 32000 percent

I have a database with a 3G datafile, and 1G logfile. I have set the
Autogrowth on the datafile to 250M, for the third time. Somehow, I don't know
when, the Autogrowth is getting changed to [32000 percent]. So when the
datafile tries to expand it take a considerable amount of disk space (106G),
then my log dumps start failing due to low disk space.
Autogrowth=32000%
Has anyone seen this before?
Thanks in advance,
KenL wrote:
> I have a database with a 3G datafile, and 1G logfile. I have set the
> Autogrowth on the datafile to 250M, for the third time. Somehow, I don't know
> when, the Autogrowth is getting changed to [32000 percent]. So when the
> datafile tries to expand it take a considerable amount of disk space (106G),
> then my log dumps start failing due to low disk space.
> Autogrowth=32000%
> Has anyone seen this before?
> Thanks in advance,
You don't say, but I'm assuming this is on SQL 2005? This is a known
bug:
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127177
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Tracy, thanks very much for the response. The feedback referenced below is
talking about SQL 2000, and says it will be fixed in the next release of SQL
Server. I am using SQL 2005, so isn't that the next release? I do not see a
resolution?
Thanks,
"Tracy McKibben" wrote:

> KenL wrote:
> You don't say, but I'm assuming this is on SQL 2005? This is a known
> bug:
> http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127177
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||KenL wrote:
> Tracy, thanks very much for the response. The feedback referenced below is
> talking about SQL 2000, and says it will be fixed in the next release of SQL
> Server. I am using SQL 2005, so isn't that the next release? I do not see a
> resolution?
No, this is definately a SQL 2005 bug... The article that I linked to
talks about one possible cause of this as being a status bit in a
converted SQL 2000 database.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Tracy, again thanks for the response.
The database is in SQL 2005, and was upgraded from a SQL 7 to SQL 2000, and
then SQL 2005. So are your saying this is a known bug that there currently is
no fix or workaround?
Thanks,
Ken
"Tracy McKibben" wrote:

> KenL wrote:
> No, this is definately a SQL 2005 bug... The article that I linked to
> talks about one possible cause of this as being a status bit in a
> converted SQL 2000 database.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>

Autogrowth 32000 percent

I have a database with a 3G datafile, and 1G logfile. I have set the
Autogrowth on the datafile to 250M, for the third time. Somehow, I don't kno
w
when, the Autogrowth is getting changed to [32000 percent]. So when the
datafile tries to expand it take a considerable amount of disk space (106G),
then my log dumps start failing due to low disk space.
Autogrowth=32000%
Has anyone seen this before?
Thanks in advance,KenL wrote:
> I have a database with a 3G datafile, and 1G logfile. I have set the
> Autogrowth on the datafile to 250M, for the third time. Somehow, I don't k
now
> when, the Autogrowth is getting changed to [32000 percent]. So when th
e
> datafile tries to expand it take a considerable amount of disk space (106G
),
> then my log dumps start failing due to low disk space.
> Autogrowth=32000%
> Has anyone seen this before?
> Thanks in advance,
You don't say, but I'm assuming this is on SQL 2005? This is a known
bug:
http://connect.microsoft.com/SQLSer...=12717
7
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy, thanks very much for the response. The feedback referenced below is
talking about SQL 2000, and says it will be fixed in the next release of SQL
Server. I am using SQL 2005, so isn't that the next release? I do not see a
resolution?
Thanks,
"Tracy McKibben" wrote:

> KenL wrote:
> You don't say, but I'm assuming this is on SQL 2005? This is a known
> bug:
> http://connect.microsoft.com/SQLSer...=127
177
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||KenL wrote:
> Tracy, thanks very much for the response. The feedback referenced below is
> talking about SQL 2000, and says it will be fixed in the next release of S
QL
> Server. I am using SQL 2005, so isn't that the next release? I do not see
a
> resolution?
No, this is definately a SQL 2005 bug... The article that I linked to
talks about one possible cause of this as being a status bit in a
converted SQL 2000 database.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy, again thanks for the response.
The database is in SQL 2005, and was upgraded from a SQL 7 to SQL 2000, and
then SQL 2005. So are your saying this is a known bug that there currently i
s
no fix or workaround?
Thanks,
Ken
"Tracy McKibben" wrote:

> KenL wrote:
> No, this is definately a SQL 2005 bug... The article that I linked to
> talks about one possible cause of this as being a status bit in a
> converted SQL 2000 database.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>

Autogrowth 32000 percent

I have a database with a 3G datafile, and 1G logfile. I have set the
Autogrowth on the datafile to 250M, for the third time. Somehow, I don't know
when, the Autogrowth is getting changed to [32000 percent]. So when the
datafile tries to expand it take a considerable amount of disk space (106G),
then my log dumps start failing due to low disk space.
Autogrowth=32000%
Has anyone seen this before?
Thanks in advance,KenL wrote:
> I have a database with a 3G datafile, and 1G logfile. I have set the
> Autogrowth on the datafile to 250M, for the third time. Somehow, I don't know
> when, the Autogrowth is getting changed to [32000 percent]. So when the
> datafile tries to expand it take a considerable amount of disk space (106G),
> then my log dumps start failing due to low disk space.
> Autogrowth=32000%
> Has anyone seen this before?
> Thanks in advance,
You don't say, but I'm assuming this is on SQL 2005? This is a known
bug:
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127177
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy, thanks very much for the response. The feedback referenced below is
talking about SQL 2000, and says it will be fixed in the next release of SQL
Server. I am using SQL 2005, so isn't that the next release? I do not see a
resolution?
Thanks,
"Tracy McKibben" wrote:
> KenL wrote:
> > I have a database with a 3G datafile, and 1G logfile. I have set the
> > Autogrowth on the datafile to 250M, for the third time. Somehow, I don't know
> > when, the Autogrowth is getting changed to [32000 percent]. So when the
> > datafile tries to expand it take a considerable amount of disk space (106G),
> > then my log dumps start failing due to low disk space.
> >
> > Autogrowth=32000%
> > Has anyone seen this before?
> >
> > Thanks in advance,
> You don't say, but I'm assuming this is on SQL 2005? This is a known
> bug:
> http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127177
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||KenL wrote:
> Tracy, thanks very much for the response. The feedback referenced below is
> talking about SQL 2000, and says it will be fixed in the next release of SQL
> Server. I am using SQL 2005, so isn't that the next release? I do not see a
> resolution?
No, this is definately a SQL 2005 bug... The article that I linked to
talks about one possible cause of this as being a status bit in a
converted SQL 2000 database.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Tracy, again thanks for the response.
The database is in SQL 2005, and was upgraded from a SQL 7 to SQL 2000, and
then SQL 2005. So are your saying this is a known bug that there currently is
no fix or workaround?
Thanks,
Ken
"Tracy McKibben" wrote:
> KenL wrote:
> > Tracy, thanks very much for the response. The feedback referenced below is
> > talking about SQL 2000, and says it will be fixed in the next release of SQL
> > Server. I am using SQL 2005, so isn't that the next release? I do not see a
> > resolution?
> No, this is definately a SQL 2005 bug... The article that I linked to
> talks about one possible cause of this as being a status bit in a
> converted SQL 2000 database.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>

auto-grow gotcha

I made a database to hold recordings of calls made to our customers.
When I made it I set the size of the primary datafile to 18GB. It's
been running flawlessly for over 10 months. A few days ago the users
were suddenly no longer able to save the recordings to the database.
They got an error message to the effect that the timeout had expired.
The failure occurred on the .Execute statement of the Command that
calls the stored procedure.

I noticed that the data had reached the size allocated for the file.
The file was set to auto-grow (5%). However, since I couldn't find
anything else wrong, and since the test version of the database (which
only has 15GB of data in an 18GB-dimensioned file) did not exhibit the
same behavior, I decided to try increasing the size of the file with
an ALTER DATABASE statement. I increased it to 21GB. Lo and behold,
the problem disappeared.

Here's what I think might be going on: The default timeout for the
ADO Command object is 30 seconds... this is probably not long enough
for SQL Server to add 900 MB to the datafile, therefore the Command
timeout expired. So from now on instead of relying on auto-grow, I'm
going to just make sure the datafile always has plenty of headroom.

FWIW."Ellen K." <72322.enno.esspeeayem.1016@.compuserve.com> wrote in message
news:0rlntvou1j40dr2fbo1fs5uv06ir3cf89a@.4ax.com...
> I made a database to hold recordings of calls made to our customers.
> When I made it I set the size of the primary datafile to 18GB. It's
> been running flawlessly for over 10 months. A few days ago the users
> were suddenly no longer able to save the recordings to the database.
> They got an error message to the effect that the timeout had expired.
> The failure occurred on the .Execute statement of the Command that
> calls the stored procedure.
> I noticed that the data had reached the size allocated for the file.
> The file was set to auto-grow (5%). However, since I couldn't find
> anything else wrong, and since the test version of the database (which
> only has 15GB of data in an 18GB-dimensioned file) did not exhibit the
> same behavior, I decided to try increasing the size of the file with
> an ALTER DATABASE statement. I increased it to 21GB. Lo and behold,
> the problem disappeared.
> Here's what I think might be going on: The default timeout for the
> ADO Command object is 30 seconds... this is probably not long enough
> for SQL Server to add 900 MB to the datafile, therefore the Command
> timeout expired. So from now on instead of relying on auto-grow, I'm
> going to just make sure the datafile always has plenty of headroom.

The other option is to set it to grow by a fixed amount (say 500 MB) each
time rather than a %. As you found out, that % growth adds up quickly.

But I think your solution is the best, to pro-actively grow it.

(Since the next problem you'll encounter is is needing to grow say 900MB,
but finding out you have 500 MB free. Autogrow won't work and you're
basically stuck. :-)

And yes, I've been bit by this too.

> FWIW.