I want to develop a process for refreshing some reporting tables. For the minute it’s enough to assume that we have a fact table that gets refreshed every night. It takes about 30 seconds, during which, if you ran a report off the table it would have zero rows in it and your report would give you the wrong answer. This is clearly unacceptable. To move away from this, I want to know whether there are risks associated with the following strategy (assume my fact table is just called MyFacts for the purposes of this discussion):
1. Do a SELECT...INTO to create a
staging table (MyFactsStg) that
contains all data of correct type
and nullability (but no
indexes or keys yet)
2. Rename the indexes on MyFacts to
*Old
3. Add primary key and create indexes
on MyFactsStg using the object names
that were previously on MyFacts (but
which have since been renamed to
*Old. This (MyFactsStg) is now in terms of DDL, an exact copy of
MyFacts, but with more current rows
4. Rename table MyFacts to MyFactsOld
5. Rename table MyFactsStg to MyFacts
6. Drop table MyFactsOld
Taking it at face value, it seems the only downtime for the users will be a few milliseconds between steps 4 and 5. As far as my testing goes, if someone is using MyFacts while I’m trying to rename it, the rename sproc appears to wait patiently until it has exclusive access to the table and then renames it, so it appears all but seamless to the end user. What worries me is that I didn’t read about this strategy in a book so it’s probably full of gotchas that I have not thought of yet.
↧