Autogrowth in MB comes back as % after reboot by Erland Sommarskog

I have the same issue as Tore11.

Autogrowth on a SQL Server 2005 SP2 created database is initially set to 1024 MB. Without a service cycle, reboot or detach and attach, Filegrowth value 'dynamically' changes to a large percentage number. This has happened on two seperate machines running XP SP2 and SQL 2005 SP2. A fix other than checking it and changing via ALTER DATABASE or using only a percentage based Filegrowth value would be nice. I have seen in several postings this is related only to SQL 2000 upgraded databases...not true here. I have also seen this was supposed to be fixed in SP2...still having the issue.

Customer is understanding, but still costing time on both ends.

I have the same issue with SQL 2005. It changed to autogrowth by 130172 percent.

I have the same issue where it changes my auto growth to a percentage (32000%) out of the blue and I get an out of disk space issue. Hopefully it can be fixed in the next service pack.

Is there any update for this issue? From what I have seen of the fix list in SP 2, this isn't included. We need to know how to address this.
Thanks.

I have also noticed this , but it can happen without me restoring the database. It just starts to happen after a few months of usage... I normally notice this when my DB server runs out of Disk space and then I find the reason that the percentage has increased to 1280%........This has happened on different servers/databases.

This should be fixed in the next SQL Server service pack.

Hi Erland, This appears to be due to a bug that dates back to SQL 7. Basically, whether the growth value is a percent or not is kept as a status bit. There are two copies of that status bit and one copy was not being maintained correctly when growth was changed from a % value to a fixed value and vice-versa. Basically, your backup says in one place that the growth is in percentage and in the other its says it is not. We have fixed this for the next release of SQL Server, but existing databases that have this disconnect might still run into issues when they upgrade. Here is a script you can run against SQL 2000 to see the problem where the status bit is not being maintained in both places.

create database foo
go
use foo
go
alter database foo modify file (name='foo', filegrowth= 100%)
go
select 'percent' = status & 0x100000
from sysfiles1
where fileid = 1
go
select 'percent' = status & 0x100000
from sysfiles
where fileid = 1
go
alter database foo modify file (name='foo', filegrowth= 1MB)
go
select 'percent' = status & 0x100000
from sysfiles1
where fileid = 1
go
select 'percent' = status & 0x100000
from sysfiles
where fileid = 1
go
use master
go
drop database foo
go

Thank you.