DB file size grows - with double size. DB grows at random interva

Anyone had anything like this?
Background:
The essential problem is that the data and transaction log files for select
SQL Server 2000 databases on one of 2 SQL Server 2000 servers (the two
servers are not related via shared databases, replication, etc.) have been
ballooning at seemingly random intervals. But the data file sizes have
appeared to follow a pattern. In general, the pattern appears to be that the
data file increases by the approximate amount of the original file size each
time it balloons (e.g. a file data.mdf is originally 7GB; the first time it
balloons, it grows to 14GB, the second time, 21GB, etc.). At the same time,
the transaction log file grows by a tremendous amount as well (apparently far
beyond the size to which it has ever previously grown), though the file size
pattern seems less clear with the transaction log files.
Severity:
One of the databases with this problem has a data file that is about 30GB
(proper size), and the other database with this problem is about 10GB (proper
size). If MSSQL Server is unlucky—and the databases balloon two or three
times—all remaining disk space could easily be consumed, causing the server
to go down.
Hypothesis:
My hypothesis was that there was some kind of corruption in the data file,
and SQL Server allocated an amount of disk space equal to the size of the
original data store so that it could produce a second, clean copy. And the
transaction log file is keeping track of the operations SQL Server is
performing when it produces this second copy (it’s easy to see why
duplicating a complex 7GB data store can easily cause a transaction log file
to balloon as well). But, if I’m correct, then something would seem to be
very wrong with the hard disk, SQL Server, or the OS environment, because SQL
Server should be smart enough to identify relatively miniscule regions that
are corrupt and continue to work with the remaining data store. For it to
require a completely new disk allocation seems odd.
Hi Rei,
For the databases, are they set to autogrowth? Which is the autogrowth
configuration? (for example, autogrowth by 10 percent).
Ben Nevarez
"Rei" wrote:

> Anyone had anything like this?
> Background:
> The essential problem is that the data and transaction log files for select
> SQL Server 2000 databases on one of 2 SQL Server 2000 servers (the two
> servers are not related via shared databases, replication, etc.) have been
> ballooning at seemingly random intervals. But the data file sizes have
> appeared to follow a pattern. In general, the pattern appears to be that the
> data file increases by the approximate amount of the original file size each
> time it balloons (e.g. a file data.mdf is originally 7GB; the first time it
> balloons, it grows to 14GB, the second time, 21GB, etc.). At the same time,
> the transaction log file grows by a tremendous amount as well (apparently far
> beyond the size to which it has ever previously grown), though the file size
> pattern seems less clear with the transaction log files.
> Severity:
> One of the databases with this problem has a data file that is about 30GB
> (proper size), and the other database with this problem is about 10GB (proper
> size). If MSSQL Server is unlucky—and the databases balloon two or three
> times—all remaining disk space could easily be consumed, causing the server
> to go down.
> Hypothesis:
> My hypothesis was that there was some kind of corruption in the data file,
> and SQL Server allocated an amount of disk space equal to the size of the
> original data store so that it could produce a second, clean copy. And the
> transaction log file is keeping track of the operations SQL Server is
> performing when it produces this second copy (it’s easy to see why
> duplicating a complex 7GB data store can easily cause a transaction log file
> to balloon as well). But, if I’m correct, then something would seem to be
> very wrong with the hard disk, SQL Server, or the OS environment, because SQL
> Server should be smart enough to identify relatively miniscule regions that
> are corrupt and continue to work with the remaining data store. For it to
> require a completely new disk allocation seems odd.
>
|||Yes, they have 10% auto grow.
But its size doubles.
"Ben Nevarez" wrote:
[vbcol=seagreen]
> Hi Rei,
> For the databases, are they set to autogrowth? Which is the autogrowth
> configuration? (for example, autogrowth by 10 percent).
> Ben Nevarez
>
>
> "Rei" wrote:
|||Hi
If you are going to have autogrow then you should change this to a fixed
amount anyhow.
You don't say if this growth is sudden or not, have you tried to shrink the
file and monitor using perfmon when it grows? Do you run maintenance on this
database?
John
"Rei" wrote:
[vbcol=seagreen]
> Yes, they have 10% auto grow.
> But its size doubles.
> "Ben Nevarez" wrote:
|||John Bell wrote:[vbcol=seagreen]
> Hi
> If you are going to have autogrow then you should change this to a fixed
> amount anyhow.
> You don't say if this growth is sudden or not, have you tried to shrink the
> file and monitor using perfmon when it grows? Do you run maintenance on this
> database?
> John
> "Rei" wrote:
>
When the transaction log grows by a lot - that means there are a lot of
transactions being processed (read, lots of data added). This would
indicate that there is some process loading lots of data. Find those
processes, and you will find out what is causing the databases to grow.