Showing posts with label inserts. Show all posts
Showing posts with label inserts. Show all posts

Friday, March 23, 2012

Runaway log files

Hello,

I am administering a DB which is about 2GB in size and sees few hundred,
maybe up to a few thousand inserts a day plus very few deletions and updates
(less than few hundred). DB has about 200,000 records in it total. For some
time now I have noticed that the transaction logs grow a lot -- like 1GB per
day. I don't know why they are growing so much and would like to find out
why - DB usage that I know of cannot cause such a high growth, to my best
knowledge.

Is there a way to find out what is causing such growth? Can I examine these
logs somehow and see what is in them? I am worried that somehow someone
managed to run mass updates on the DB without my knowledge.

Thanks for help,

Tom Kitta"Tom Kitta" <tom@.energyshop.com> wrote in message
news:D527b.28080$mk1.4594@.news02.bloor.is.net.cabl e.rogers.com...
> Hello,
> I am administering a DB which is about 2GB in size and sees few hundred,
> maybe up to a few thousand inserts a day plus very few deletions and
updates
> (less than few hundred). DB has about 200,000 records in it total. For
some
> time now I have noticed that the transaction logs grow a lot -- like 1GB
per
> day. I don't know why they are growing so much and would like to find out
> why - DB usage that I know of cannot cause such a high growth, to my best
> knowledge.
> Is there a way to find out what is causing such growth? Can I examine
these
> logs somehow and see what is in them? I am worried that somehow someone
> managed to run mass updates on the DB without my knowledge.
> Thanks for help,
> Tom Kitta

Do you mean that your log is growing continuously? That may be normal,
depending on your backup strategy - if you're in Full recovery mode, but
never back up the log, for example. If that's the case, you can look at
backing up the log regularly or changing to Simple recovery mode.

If you're doing that already, and you mean that the log grows more over a
day than you expect, then one possibility is to use Profiler to trace the
"Log File Auto Grow" event, and look for other events before it in the trace
output. If there are one or two queries that require lots of log space, you
should be able to identify them.

Simon

Saturday, February 25, 2012

Run 2nd SQL in stored proc

I have a stored procedure (see below) that inserts records into a history
table from a source table (PayTotals). After that is successful, I would
like to run a delete statement "DELETE FROM dbo.PayTotals WHERE PaidYr =
@.PaidYr" but only if the previous INSERT is successful. What would I need
to add to the proc below to make that happen? Thanks.
David
CREATE PROCEDURE [mc_inshstPayTotals]
(@.PaidYr [smallint])
AS INSERT INTO dbo.hstPayTotals
([EmployerCaseNumber],
[EmployerMax],
[PayFirst],
[PaySecond],
[PaidYr],
[PaidMo])
SELECT
EmployerCaseNumber,
EmployerMax,
PayFirst,
PaySecond,
PaidYr,
PaidMo
FROM dbo.PayTotals
WHERE PaidYr = @.PaidYr
GOWhat does "successful" mean? If it means exactly one row is inserted:
IF @.@.ROWCOUNT = 1
BEGIN
DELETE ...
END
Otherwise, you'll have to be more specific...
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:OdaU4pF8FHA.2616@.TK2MSFTNGP15.phx.gbl...
>I have a stored procedure (see below) that inserts records into a history
>table from a source table (PayTotals). After that is successful, I would
>like to run a delete statement "DELETE FROM dbo.PayTotals WHERE PaidYr =
>@.PaidYr" but only if the previous INSERT is successful. What would I need
>to add to the proc below to make that happen? Thanks.
> David
> CREATE PROCEDURE [mc_inshstPayTotals]
> (@.PaidYr [smallint])
> AS INSERT INTO dbo.hstPayTotals
> ([EmployerCaseNumber],
> [EmployerMax],
> [PayFirst],
> [PaySecond],
> [PaidYr],
> [PaidMo])
> SELECT
> EmployerCaseNumber,
> EmployerMax,
> PayFirst,
> PaySecond,
> PaidYr,
> PaidMo
> FROM dbo.PayTotals
> WHERE PaidYr = @.PaidYr
> GO
>|||The system variable @.@.rowcount will return the number of rows affected (in
this case inserted). Also, there is the variable @.@.error that contains <> 0
in the event of an error.
For example:
insert into ...
if @.@.rowcount > 0
begin
..
end
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:OdaU4pF8FHA.2616@.TK2MSFTNGP15.phx.gbl...
>I have a stored procedure (see below) that inserts records into a history
>table from a source table (PayTotals). After that is successful, I would
>like to run a delete statement "DELETE FROM dbo.PayTotals WHERE PaidYr =
>@.PaidYr" but only if the previous INSERT is successful. What would I need
>to add to the proc below to make that happen? Thanks.
> David
> CREATE PROCEDURE [mc_inshstPayTotals]
> (@.PaidYr [smallint])
> AS INSERT INTO dbo.hstPayTotals
> ([EmployerCaseNumber],
> [EmployerMax],
> [PayFirst],
> [PaySecond],
> [PaidYr],
> [PaidMo])
> SELECT
> EmployerCaseNumber,
> EmployerMax,
> PayFirst,
> PaySecond,
> PaidYr,
> PaidMo
> FROM dbo.PayTotals
> WHERE PaidYr = @.PaidYr
> GO
>|||The INSERT will always handle thousands of records, so I would think
that if the @.@.rowcount was > 0 then it worked, correct?
David
*** Sent via Developersdex http://www.examnotes.net ***|||JT,
If there IS an error, won't the @.@.rowcount = 0?
Thanks.
*** Sent via Developersdex http://www.examnotes.net ***|||Yes, I would expect that to be the case.
Just because @.@.error = 0, it doesn't necessarily mean that 0 rows were
inserted, becuase the select query may return no rows or a trigger on
hstPayTotals may rollback the insert. Therefore, you will want to at least
check the status of @.@.rowcount.
"David" <daman@.lifetime.com> wrote in message
news:unZmE0F8FHA.1864@.TK2MSFTNGP12.phx.gbl...
> JT,
> If there IS an error, won't the @.@.rowcount = 0?
> Thanks.
>
> *** Sent via Developersdex http://www.examnotes.net ***|||> The INSERT will always handle thousands of records, so I would think
> that if the @.@.rowcount was > 0 then it worked, correct?
Well, again, just because you inserted a bunch of rows doesn't necessarily
mean they were the right ones. :-)
But yes, if all you care about is that at least one row was inserted, then
checking for a positive @.@.ROWCOUNT should suffice.|||>I have a stored procedure (see below) that inserts records into a history
>table from a source table (PayTotals). After that is successful, I would
>like to run a delete statement "DELETE FROM dbo.PayTotals WHERE PaidYr =
>@.PaidYr" but only if the previous INSERT is successful. What would I need
>to add to the proc below to make that happen? Thanks.
I must be missing something in the midst of all this discussion of
@.@.ROWCOUNT and @.@.ERROR. Perhaps I'm being retarded today, but why not just
do this:
BEGIN TRANSACTION
INSERT stuff
DELETE stuff
COMMIT TRANSACTION
Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane|||"Mike Labosh" <mlabosh@.hotmail.com> wrote in message
news:%23kJ4e7G8FHA.2616@.TK2MSFTNGP15.phx.gbl...
> I must be missing something in the midst of all this discussion of
> @.@.ROWCOUNT and @.@.ERROR. Perhaps I'm being retarded today, but why not
> just do this:
> BEGIN TRANSACTION
> INSERT stuff
> DELETE stuff
> COMMIT TRANSACTION
It depends what you want to do if the INSERT fails.
Do you still want to DELETE?
And if the INSERT succedes and the DELETE fails.
Do you still want to Commit the INSERT.
Normally you don't.
So after each one, check @.@.rowcount and @.@.errors and Commit only if both
succede.
Else, Rollback.