|
|
Posted by Tony Rogerson on 05/11/06 12:04
> 2) Create the clustered index on the target table with a relatively low
> fill factor, say 30%. (Of course, no NC indexes would be in place.)
As the table is empty there is no point putting on the fillfactor because
its not enforced for new pages.
Only good for creating indexes on existing data.
I agree though - clustered index should be in place before you start.
--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
news:Xns97BFF29DB95D8Yazorman@127.0.0.1...
> sql_server_user (kaioptera@gmail.com) writes:
>> I'm trying to copy all 440 million rows from one table in my SQL Server
>> 2005 db to another table with a different clustering scheme. After a
>> few test inserts that were successful (up to a million rows in 20
>> seconds with no problem), I crossed my fingers and went whole-hog with
>> the naive "insert into dest_table (column1, column2, ...) select
>> column1, column2, ... from source_table" but of course it ran out of
>> space in *both* the db log file (at about 130 GB) and the tempdb log
>> file (at about 54GB) and rolled it back, wrapping up 10 hours after I
>> kicked it off.
>
> That operation is definitely not a walk in a park.
>
> I think I would attempt this strategy:
>
> 1) Set recovery for the database to simple recovery.
> 2) Create the clustered index on the target table with a relatively low
> fill factor, say 30%. (Of course, no NC indexes would be in place.)
> 3) Insert batchwise from the old table, where batches are defined by
> intervals of the clustered index of the source table. For batchsize,
> I would use 100000 to 500000 rows, depending on wide the table is.
> 4) I would make the control loop so that it is easy to stop it. For
> instance on each iteration read from a control table. Possibly also
> a table the defines the batches, so you can keep track of what has
> been copied. But the table should not be joined with the INSERT;
> read interval into variales.
> 5) Occassionally stop the process and monitor fragmentation in
> target table. It should first decrease, as holes are filled in,
> but then it will increase again. (But you will probably see this
> from the fact that the time for iteration increases.)
> 6) Once everything is done, switch to full recovery and backup the
> database.
>
> My thinking here is that creating the clustered index on this monster
> is going require a lot of log and tempdb - you can guess what happens.
> So let's have the clustered index in place from the start, even if
> that will take longer time.
>
>
>
> --
> 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
Navigation:
[Reply to this message]
|