Showing posts with label insert. Show all posts
Showing posts with label insert. Show all posts

Monday, March 19, 2012

Log file grew big ?

We have a table in SQL Server with 3 columns, and 1 of the columns is a
varchar(2000) column.
The database has a "simple" recovery model.
We insert data in the database every millisecond.
Every day, we delete data from the table that is older than 1 w old.
We then changed the column to be varchar(100), because the data is more
compact now.
Since we do this, I notice the log file grew from less than 100 meg to 2
gig. The data file is about 500 meg.
Why is the log file grew so much once I changed 1 of the column to be
varchar(100) ? Thank you very much.
Here is the stored procedure to delete data every day.
CREATE PROCEDURE DeleteDataInBatch
AS
declare @.LastCount smallint
set ROWCOUNT 5000
set @.LastCount = 1
while (@.LastCount > 0)
begin
begin tran
delete from ...
set @.LastCount = @.@.ROWCOUNT
commit tran
end
set ROWCOUNT 0
GO
Here is the stored procedure to insert data.
CREATE PROCEDURE InsertData
@.sContract varchar(8),
@.sData varchar(2000)
AS
insert into ...
GODid you use Enterprise manager to do the change? If so it usually creates a
new table behind the scenes, copies all the data over to it and then drops
the original table. All of this is fully logged and will require lots of
space.
Andrew J. Kelly SQL MVP
"fniles" <fniles@.pfmail.com> wrote in message
news:uhAArB1RFHA.3944@.TK2MSFTNGP10.phx.gbl...
> We have a table in SQL Server with 3 columns, and 1 of the columns is a
> varchar(2000) column.
> The database has a "simple" recovery model.
> We insert data in the database every millisecond.
> Every day, we delete data from the table that is older than 1 w old.
> We then changed the column to be varchar(100), because the data is more
> compact now.
> Since we do this, I notice the log file grew from less than 100 meg to 2
> gig. The data file is about 500 meg.
> Why is the log file grew so much once I changed 1 of the column to be
> varchar(100) ? Thank you very much.
> Here is the stored procedure to delete data every day.
> CREATE PROCEDURE DeleteDataInBatch
> AS
> declare @.LastCount smallint
> set ROWCOUNT 5000
> set @.LastCount = 1
> while (@.LastCount > 0)
> begin
> begin tran
> delete from ...
> set @.LastCount = @.@.ROWCOUNT
> commit tran
> end
> set ROWCOUNT 0
> GO
> Here is the stored procedure to insert data.
> CREATE PROCEDURE InsertData
> @.sContract varchar(8),
> @.sData varchar(2000)
> AS
> insert into ...
> GO
>|||> Did you use Enterprise manager to do the change?
Yes, I changed the column from varchar(2000) to varchar(100) in EM.
So, you think the log file grew big during the process of changing the
column from varchar(2000) to varchar(100) in EM ?
I though I checked the log file size after I did that, but I might be wrong.
With a log file 2 gig in size, will it slow down any querying, inserting or
deleting in the database ?
Do I need and can I shrink this log file size, or shall I leave it alone ?
Thank you very much.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:OPBHJb1RFHA.164@.TK2MSFTNGP12.phx.gbl...
> Did you use Enterprise manager to do the change? If so it usually creates
> a new table behind the scenes, copies all the data over to it and then
> drops the original table. All of this is fully logged and will require
> lots of space.
> --
> Andrew J. Kelly SQL MVP
>
> "fniles" wrote in message news:uhAArB1RFHA.3944@.TK2MSFTNGP10.phx.gbl...
>|||I usually set my database log files to about 20 to 30 % of the total databas
e
space.
Also depends on how transaction intensive your database is.
I always restrict my log file size to a maximum value.
I do not thing you woul gain anything by having that big a log file size. I
woud have shrunk it after backing up the database and doing a dump of the
transaction log.
Nishant
"fniles" wrote:

> Yes, I changed the column from varchar(2000) to varchar(100) in EM.
> So, you think the log file grew big during the process of changing the
> column from varchar(2000) to varchar(100) in EM ?
> I though I checked the log file size after I did that, but I might be wron
g.
> With a log file 2 gig in size, will it slow down any querying, inserting o
r
> deleting in the database ?
> Do I need and can I shrink this log file size, or shall I leave it alone ?
> Thank you very much.
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:OPBHJb1RFHA.164@.TK2MSFTNGP12.phx.gbl...
>
>|||Thank you for your reply.
I do not want the log file to be that big.
We insert data to the database every miliseconds, currently the database is
about 500 meg in size and has about 15 million records in this table.
Is it too late to restrict the log file size now that it already grew to 2
gig ?
If I restrict the log file size, will it slow down inserting and deleting ?
How do I dump the transaction log ?
If I shrink the transaction log, will it slow down inserting and deleting
later ?
Thank you very much.
"NB" <NB@.discussions.microsoft.com> wrote in message
news:705DD5E1-3F87-4D71-86DD-AAFA78DE424A@.microsoft.com...
>I usually set my database log files to about 20 to 30 % of the total
>database
> space.
> Also depends on how transaction intensive your database is.
> I always restrict my log file size to a maximum value.
> I do not thing you woul gain anything by having that big a log file size.
> I
> woud have shrunk it after backing up the database and doing a dump of the
> transaction log.
>
> Nishant
> "fniles" wrote:
>|||There's no penalty to have a "too big" file. Having a small file does come w
ith a penalty, however:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"NB" <NB@.discussions.microsoft.com> wrote in message
news:705DD5E1-3F87-4D71-86DD-AAFA78DE424A@.microsoft.com...
>I usually set my database log files to about 20 to 30 % of the total databa
se
> space.
> Also depends on how transaction intensive your database is.
> I always restrict my log file size to a maximum value.
> I do not thing you woul gain anything by having that big a log file size.
I
> woud have shrunk it after backing up the database and doing a dump of the
> transaction log.
>
> Nishant
> "fniles" wrote:
>

Monday, February 20, 2012

Locks on a table

For some reason, one table in our database (SQL 2000) keeps getting locks on
it so attempts to insert records on it seems to time out frequently. Any
ideas on what I might look for to keep this from happening? The table has
only a unique int for a PK and no other indexes. Thanks.David wrote:
> For some reason, one table in our database (SQL 2000) keeps getting locks on
> it so attempts to insert records on it seems to time out frequently. Any
> ideas on what I might look for to keep this from happening? The table has
> only a unique int for a PK and no other indexes. Thanks.
>
When the locking occurs, look at sp_lock, sp_who2, determine what spid
is locking the table. Then use DBCC INPUTBUFFER to see what that spid
is doing. My guess is that something is table-scanning the table, maybe
a sign that additional indexes are needed.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I'm not sure if this helps, but when I go into EM and look at the
Locks/process ID and click on a couple of the spid records, I see the
following entry in the objects list on a couple of the spid records:
Object = tempdb.dbo.##lockinfo67
Lock Type = TAB
Mode = X
Status = GRANT
Owner = Xact
Index = ##lockinfo67
Not sure if this helps.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45ACFD6F.3060409@.realsqlguy.com...
> David wrote:
>> For some reason, one table in our database (SQL 2000) keeps getting locks
>> on it so attempts to insert records on it seems to time out frequently.
>> Any ideas on what I might look for to keep this from happening? The
>> table has only a unique int for a PK and no other indexes. Thanks.
> When the locking occurs, look at sp_lock, sp_who2, determine what spid is
> locking the table. Then use DBCC INPUTBUFFER to see what that spid is
> doing. My guess is that something is table-scanning the table, maybe a
> sign that additional indexes are needed.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||David wrote:
> I'm not sure if this helps, but when I go into EM and look at the
> Locks/process ID and click on a couple of the spid records, I see the
> following entry in the objects list on a couple of the spid records:
> Object = tempdb.dbo.##lockinfo67
> Lock Type = TAB
> Mode = X
> Status = GRANT
> Owner = Xact
> Index = ##lockinfo67
> Not sure if this helps.
>
Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||OK. It looks like there is a missing index on a critical FK field on a
frequently used table. I think your comment about doing table scans is
probably correct. I'm going to add an index tonight and see if the problem
goes away.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45AD017B.40400@.realsqlguy.com...
> David wrote:
>> I'm not sure if this helps, but when I go into EM and look at the
>> Locks/process ID and click on a couple of the spid records, I see the
>> following entry in the objects list on a couple of the spid records:
>> Object = tempdb.dbo.##lockinfo67
>> Lock Type = TAB
>> Mode = X
>> Status = GRANT
>> Owner = Xact
>> Index = ##lockinfo67
>> Not sure if this helps.
> Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the problem
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the problem
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com

Locks on a table

For some reason, one table in our database (SQL 2000) keeps getting locks on
it so attempts to insert records on it seems to time out frequently. Any
ideas on what I might look for to keep this from happening? The table has
only a unique int for a PK and no other indexes. Thanks.David wrote:
> For some reason, one table in our database (SQL 2000) keeps getting locks
on
> it so attempts to insert records on it seems to time out frequently. Any
> ideas on what I might look for to keep this from happening? The table has
> only a unique int for a PK and no other indexes. Thanks.
>
When the locking occurs, look at sp_lock, sp_who2, determine what spid
is locking the table. Then use DBCC INPUTBUFFER to see what that spid
is doing. My guess is that something is table-scanning the table, maybe
a sign that additional indexes are needed.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I'm not sure if this helps, but when I go into EM and look at the
Locks/process ID and click on a couple of the spid records, I see the
following entry in the objects list on a couple of the spid records:
Object = tempdb.dbo.##lockinfo67
Lock Type = TAB
Mode = X
Status = GRANT
Owner = Xact
Index = ##lockinfo67
Not sure if this helps.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45ACFD6F.3060409@.realsqlguy.com...
> David wrote:
> When the locking occurs, look at sp_lock, sp_who2, determine what spid is
> locking the table. Then use DBCC INPUTBUFFER to see what that spid is
> doing. My guess is that something is table-scanning the table, maybe a
> sign that additional indexes are needed.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||David wrote:
> I'm not sure if this helps, but when I go into EM and look at the
> Locks/process ID and click on a couple of the spid records, I see the
> following entry in the objects list on a couple of the spid records:
> Object = tempdb.dbo.##lockinfo67
> Lock Type = TAB
> Mode = X
> Status = GRANT
> Owner = Xact
> Index = ##lockinfo67
> Not sure if this helps.
>
Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||OK. It looks like there is a missing index on a critical FK field on a
frequently used table. I think your comment about doing table scans is
probably correct. I'm going to add an index tonight and see if the problem
goes away.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45AD017B.40400@.realsqlguy.com...
> David wrote:
> Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the proble
m
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the proble
m
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com

Locks on a table

For some reason, one table in our database (SQL 2000) keeps getting locks on
it so attempts to insert records on it seems to time out frequently. Any
ideas on what I might look for to keep this from happening? The table has
only a unique int for a PK and no other indexes. Thanks.
David wrote:
> For some reason, one table in our database (SQL 2000) keeps getting locks on
> it so attempts to insert records on it seems to time out frequently. Any
> ideas on what I might look for to keep this from happening? The table has
> only a unique int for a PK and no other indexes. Thanks.
>
When the locking occurs, look at sp_lock, sp_who2, determine what spid
is locking the table. Then use DBCC INPUTBUFFER to see what that spid
is doing. My guess is that something is table-scanning the table, maybe
a sign that additional indexes are needed.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I'm not sure if this helps, but when I go into EM and look at the
Locks/process ID and click on a couple of the spid records, I see the
following entry in the objects list on a couple of the spid records:
Object = tempdb.dbo.##lockinfo67
Lock Type = TAB
Mode = X
Status = GRANT
Owner = Xact
Index = ##lockinfo67
Not sure if this helps.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45ACFD6F.3060409@.realsqlguy.com...
> David wrote:
> When the locking occurs, look at sp_lock, sp_who2, determine what spid is
> locking the table. Then use DBCC INPUTBUFFER to see what that spid is
> doing. My guess is that something is table-scanning the table, maybe a
> sign that additional indexes are needed.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||David wrote:
> I'm not sure if this helps, but when I go into EM and look at the
> Locks/process ID and click on a couple of the spid records, I see the
> following entry in the objects list on a couple of the spid records:
> Object = tempdb.dbo.##lockinfo67
> Lock Type = TAB
> Mode = X
> Status = GRANT
> Owner = Xact
> Index = ##lockinfo67
> Not sure if this helps.
>
Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||OK. It looks like there is a missing index on a critical FK field on a
frequently used table. I think your comment about doing table scans is
probably correct. I'm going to add an index tonight and see if the problem
goes away.
David
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:45AD017B.40400@.realsqlguy.com...
> David wrote:
> Forget the GUI - go to Query Analyzer and run the stuff that I mentioned.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the problem
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||David wrote:
> OK. It looks like there is a missing index on a critical FK field on a
> frequently used table. I think your comment about doing table scans is
> probably correct. I'm going to add an index tonight and see if the problem
> goes away.
>
That'll do it!
Tracy McKibben
MCDBA
http://www.realsqlguy.com