Keep table downtime to a minimum by renaming old table, then filling a new version?

Question

I have a handful or so of permanent tables that need to be re-built on a nightly basis.

In order to keep these tables \"live\" for as long as possible, and also to

Answer 1

if you use SQL Server 2008, why can't you try to use horisontal partitioning? All data contains in one table, but new and old data contains in separate partitions.

Answer 2

Use indirection to avoid manuipulating tables directly:

• Have 3 tables: Client1, Client2, Client3 with all indexes, constraints and triggers etc
• Use synonyms to hide the real table eg Client, ClientOld, ClientToLoad
• To generate the new table, you truncate/write to "ClientToLoad"
• Then you DROP and CREATE the synonyms in a transaction so that
  • Client -> what was ClientToLoad
  • ClientOld -> what was Client
  • ClientToLoad -> what was ClientOld

You can use SELECT base_object_name FROM sys.synonyms WHERE name = 'Client' to work out what the current indirection is

This works on all editions of SQL Server: the other way is "partition switching" which requires enterprise edition

Answer 3

Except of missing step 0. Drop tbl_Client_old if exists solutions seems fine especially if you run it in explicit transaction. There is no backup of any previous data however.

The other solution, without renames and drops, and which I personally would prefer is to:

1. Copy all rows from tbl_Client to tbl_Client_old;
2. Truncate tbl_Client.
3. (Optional) Remove obsolete records from tbl_Client_old.

It's better in a way that you can control how much of the old data you can store in tbl_Client_old. Which solution will be faster depends on how much data is stored in tables and what indices in tables are.

Answer 4

Some things to keep in mind:

1. Replication - if you use replication, I don't believe you'll be able to easily implement this strategy
2. Indexes - make sure that any indexes you have on the tables are carried over to your new/old tables as needed
3. Logging - i don't remember whether or not sp_rename is fully logged, so you may want to test that in case you need to be able to rollback, etc.

Those are the possible drawbacks I can think of off the top of my head. It otherwise seems to be an effective way to handle the situation.