Dump Huge

A dump of our database is growing more huge by the week, but we aren't doing
much with it. Properties show it us about 13gb in size, but the dump three
weeks ago was 26gb, and today it is 41gb. I dumped tran with no_log and ran
shrink, but that didn't seem to do anything. What's up with this?
Jay Marvin (JayMarvin@.discussions.microsoft.com) writes:
> A dump of our database is growing more huge by the week, but we aren't
> doing much with it. Properties show it us about 13gb in size, but the
> dump three weeks ago was 26gb, and today it is 41gb. I dumped tran with
> no_log and ran shrink, but that didn't seem to do anything. What's up
> with this?
How does your BACKUP command look like? It sounds like you are backing up
the database to the same file each time, but you are not using WITH INIT.
In that case the backup is appended to the file.
You can examine this with RESTORE HEADERONLY on the backup file. If you
get more than one row back, there are multiple backups in the file.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

dual processor benefit

Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
Current db size is 62 gigabytes.
Our situation: We use Meditech hospital software which has it's own db
structure (mumps). Nightly, most of the data that is entered into the
"live" system is replicated to the SQL database. We recently upgraded the
Meditech software and now their SQL consultant is telling us that we should
be installing a second processor because their initial load program (in
which the program compares data in the Meditech system and the SQL to verify
it's all there) is taxing the CPU at >40%.
My question: Does SQL 2000 effectively utilize a second CPU or is it, as we
believe, something in the newer Meditech software that's causing the
problem?
Hi,
To directly answer your question: Yes SQL Server can utilize the processors
effectively.
But, CPU usage aprx. 40% is nothing, unless it is causing other issues on
the server. And if there were no other changes made to the server, its the
application that is causing the extra load.
hth
DeeJay Puar
"pdwight" wrote:

> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we should
> be installing a second processor because their initial load program (in
> which the program compares data in the Meditech system and the SQL to verify
> it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as we
> believe, something in the newer Meditech software that's causing the
> problem?
>
>
|||40% proc utilization is not high... If the batch + users run it up, you
may wish to get another processor... One of the big reasons to go multi proc
is to allow SQL to service 2 connections concurrently, and therefore no
single long running thing will block the processor queue...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"pdwight" <paulc@.mmcwm.com> wrote in message
news:OE6ogW$KFHA.2952@.TK2MSFTNGP10.phx.gbl...
> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we
> should be installing a second processor because their initial load program
> (in which the program compares data in the Meditech system and the SQL to
> verify it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as
> we believe, something in the newer Meditech software that's causing the
> problem?
>

dual processor benefit

Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
Current db size is 62 gigabytes.
Our situation: We use Meditech hospital software which has it's own db
structure (mumps). Nightly, most of the data that is entered into the
"live" system is replicated to the SQL database. We recently upgraded the
Meditech software and now their SQL consultant is telling us that we should
be installing a second processor because their initial load program (in
which the program compares data in the Meditech system and the SQL to verify
it's all there) is taxing the CPU at >40%.
My question: Does SQL 2000 effectively utilize a second CPU or is it, as we
believe, something in the newer Meditech software that's causing the
problem?Hi,
To directly answer your question: Yes SQL Server can utilize the processors
effectively.
But, CPU usage aprx. 40% is nothing, unless it is causing other issues on
the server. And if there were no other changes made to the server, its the
application that is causing the extra load.
hth
DeeJay Puar
"pdwight" wrote:

> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we shoul
d
> be installing a second processor because their initial load program (in
> which the program compares data in the Meditech system and the SQL to veri
fy
> it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as
we
> believe, something in the newer Meditech software that's causing the
> problem?
>
>|||40% proc utilization is not high... If the batch + users run it up, you
may wish to get another processor... One of the big reasons to go multi proc
is to allow SQL to service 2 connections concurrently, and therefore no
single long running thing will block the processor queue...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"pdwight" <paulc@.mmcwm.com> wrote in message
news:OE6ogW$KFHA.2952@.TK2MSFTNGP10.phx.gbl...
> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we
> should be installing a second processor because their initial load program
> (in which the program compares data in the Meditech system and the SQL to
> verify it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as
> we believe, something in the newer Meditech software that's causing the
> problem?
>

dual processor benefit

Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
Current db size is 62 gigabytes.
Our situation: We use Meditech hospital software which has it's own db
structure (mumps). Nightly, most of the data that is entered into the
"live" system is replicated to the SQL database. We recently upgraded the
Meditech software and now their SQL consultant is telling us that we should
be installing a second processor because their initial load program (in
which the program compares data in the Meditech system and the SQL to verify
it's all there) is taxing the CPU at >40%.
My question: Does SQL 2000 effectively utilize a second CPU or is it, as we
believe, something in the newer Meditech software that's causing the
problem?Hi,
To directly answer your question: Yes SQL Server can utilize the processors
effectively.
But, CPU usage aprx. 40% is nothing, unless it is causing other issues on
the server. And if there were no other changes made to the server, its the
application that is causing the extra load.
hth
DeeJay Puar
"pdwight" wrote:
> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we should
> be installing a second processor because their initial load program (in
> which the program compares data in the Meditech system and the SQL to verify
> it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as we
> believe, something in the newer Meditech software that's causing the
> problem?
>
>|||40% proc utilization is not high... If the batch + users run it up, you
may wish to get another processor... One of the big reasons to go multi proc
is to allow SQL to service 2 connections concurrently, and therefore no
single long running thing will block the processor queue...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"pdwight" <paulc@.mmcwm.com> wrote in message
news:OE6ogW$KFHA.2952@.TK2MSFTNGP10.phx.gbl...
> Currently running SQL 2K on a W2K sp3 box with one P3 1.2 processor.
> Current db size is 62 gigabytes.
> Our situation: We use Meditech hospital software which has it's own db
> structure (mumps). Nightly, most of the data that is entered into the
> "live" system is replicated to the SQL database. We recently upgraded the
> Meditech software and now their SQL consultant is telling us that we
> should be installing a second processor because their initial load program
> (in which the program compares data in the Meditech system and the SQL to
> verify it's all there) is taxing the CPU at >40%.
> My question: Does SQL 2000 effectively utilize a second CPU or is it, as
> we believe, something in the newer Meditech software that's causing the
> problem?
>