Antares is right.

You only can trunc the part of the commited work from the log.

If you run out of space you will loose your work anyhow, because SQLServer will roll...

Did you try to break up your upgrade by smaller parts.

I do also have similar activities to feed and after remove millions of rows.

Here is how I am working:

declare @i...

Thanks!

That was it!!!

For shure I did it.

I'm running regullary the maintenance tasks on the DB (INDEXDEFRAG, REINDEX, UPDATEUSAGE, UPDATE STATISTTICS, CHECKDB) but non of this is working on system tables.

On the other...

In fact the performance is the real issue.

We will have 3-4 applications connecting to several DB's. Approx. 1500 user, most of them are concurrent

I was thinking to make 2 servers...

Yes it's matter of space AND time.

I have an 18 GB partition for the log.

Normally I have 5 GB allocated and that's fine for the allday operation.

But when I do...

check out your recovery model.

You should have either full or bulk-logged AND you are probably not making any log backup.

If so then you only have to put your database recovery...

There is an another possibility:

You can move your big table into an another filegroup (and therefore a new file) by dropping and recreating the clustered index witn the ON FILEGROUP...

The other guys are right!

Don't use the cursor!

As I've seen your TSQL I could determint that effectivly ther will be no index usage on the sepNOBO_AnalysisTable (a_UPIDonDPUL) because of the...

Why not to use detach and attach.

So the copy could be done at the LAN speed, Attaching the DB is also fast.

So if you do not have the most accurate...

Use your favorite SQL Query Analyzer and type:

drop index TableName.IndexName

Where IndexName is your clustered index

And the type:

create clustered index IndexName on TableName(column, column...) on NewFileGroup

This one has effect...