Yes, moving a logfile to a different physical disk will always increase IO, because you're spreading your IO. But howmuch it will improve depends on your databasetype. If it's generating...

OK, after you freed some space, consider:

- buying a monitoring tool to prevent this type of errors. Or develop your own script, which runs regularly (I can give you some...

It's doesn't matter which shrink option I use (truncate, full reorg, migrate data tot other datafiles in same filegroup), SQL won't allow me to use a shrink command (same error...

I know. I'm not removing it, just shrinking (see my first post 😉 )

You only have to define the tablestructure when the resultset is a Multistatement Table-valued Functions, which is not the case. Or do I have to change the resultset in your...

statement 2 will always result the same result set: nothing

To my opinion, the answer is YES

The explanation was about a misused BETWEEN ... what a @#$!%!#

Ask yourself: What's causing this growth?

Is it a full recovery database without logbackups, or too less logbackups a day?

If the database is in simple recovery, monitor the average size...

It's not necessary to shrink the logfile before doing a full backup (if it's your intention to compact the size of your backup). Although a full backup contains all the...

check:

1) Do you run a reorganize database on a daily basis? That's blowing up your datafiles with a lot of unused space

2) Keep logging your tablesizes on a daily base...

If you want to see uncommitted data, change the transaction isolation level:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

(your statements here)

See BOL for more information about this item

fyi,

I moved the nonclustered indexes from [primary] to [index]

I moved heap tables and clustered indexes from [primary] to [data]

[primary] now only contains systemobjects (which are not movable)

Simple recovery is not...

Can you do something like this? I'm assuming you would know if "It was determined that a transaction log backup had run at the same time that the shrink was...

You can simplify your statement by doing this construction:

declare @SQLCMD nvarchar(1000)

declare @retcode bigint

set @SQLCMD = 'select count(*) from {tablename}'

exec @retcode = sp_executeSQL @SQLCMD

print @retcode

found this post on http://weblogs.sqlteam.com/tarad/category/95.aspx/rss

vrijdag 9 november 2007, 0:31:40 | Tara Kizer

Recently we purged millions of rows from a database as it was determined that we did not need to...

maybe a delete trigger is not working?