Design tips for architecting a large scale SQL data warehouse.

2. 1 - Consider partitioning large fact tables
Consider partitioning fact tables that are 50 to 100GB or larger.
Partitioning can provide manageability and often performance benefits.
Faster, more granular index maintenance.
More flexible backup / restore options.
Faster data loading and deleting
Faster queries when restricted to a single partition..
Typically partition the fact table on the date key.
Enables sliding window.
Enables partition elimination.

3. 2 - Build clustered index on date key of fact table
This supports efficient queries to populate cubes or retrieve a
historical data slice.
If you load data in a batch window then use the options
ALLOW_ROW_LOCKS = OFF and ALLOW_PAGE_LOCKS = OFF for
the clustered index on the fact table. This helps speed up table scan
operations during query time and helps avoid excessive locking
activity during large updates.
Build nonclustered indexes for each foreign key. This helps ‘pinpoint
queries' to extract rows based on a selective dimension
predicate.Use filegroups for administration requirements such as
backup / restore, partial database availability, etc.

4. 3 - Choose partition grain carefully
Most customers use month, quarter, or year.
For efficient deletes, you must delete one full partition at a
time.
It is faster to load a complete partition at a time.
Daily partitions for daily loads may be an attractive option.
However, keep in mind that a table can have a maximum of 1000
partitions.
Avoid a partition design where only 2 or 3 partitions are
touched by frequent queries, if you need MAXDOP parallelism
(assuming MAXDOP =4 or larger).

5. 4 - Design dimension tables appropriately
Use integer surrogate keys for all dimensions, other than the Date dimension. Use the
smallest possible integer for the dimension surrogate keys. This helps to keep fact table
narrow.
Use a meaningful date key of integer type derivable from the DATETIME data type (for
example: 20060215).
Don't use a surrogate Key for the Date dimension
Easy to write queries that put a WHERE clause on this column, which will allow partition
elimination of the fact table.
Build a clustered index on the surrogate key for each dimension table, and build a nonclustered index on the Business Key (potentially combined with a row-effective-date) to
support surrogate key lookups during loads.
Build nonclustered indexes on other frequently searched dimension columns.
Avoid partitioning dimension tables.

6. 5 - Write effective queries for partition elimination
Whenever possible, place a query predicate
(WHERE condition) directly on the partitioning
key (Date dimension key) of the fact table.

7. 6 - Use Sliding Window technique to maintain data
Maintain a rolling time window for online access to the fact tables. Load newest data, unload oldest data.
Always keep empty partitions at both ends of the partition range to guarantee that the partition split
(before loading new data) and partition merge (after unloading old data) do not incur any data movement.
Avoid split or merge of populated partitions. Splitting or merging populated partitions can be extremely
inefficient, as this may cause as much as 4 times more log generation, and also cause severe locking.
Create the load staging table in the same filegroup as the partition you are loading.
Create the unload staging table in the same filegroup as the partition you are deleteing.
It is fastest to load newest full partition at one time, but only possible when partition size is equal to the
data load frequency (for example, you have one partition per day, and you load data once per day).
If the partition size doesn't match the data load frequency, incrementally load the latest partition.

8. 7 - Efficiently load the initial data
Use SIMPLE or BULK LOGGED recovery model during the initial data load.
Create the partitioned fact table with the Clustered index.
Create non-indexed staging tables for each partition, and separate source data files for
populating each partition.
Build a clustered index on each staging table, then create appropriate CHECK constraints.
SWITCH all partitions into the partitioned table.
Build nonclustered indexes on the partitioned table.
Possible to load 1 TB in under an hour on a 64-CPU server with a SAN capable of 14
GB/Sec throughput (non-indexed table)

9. 8 - Efficiently delete old data
Use partition switching whenever possible.
To delete millions of rows from nonpartitioned, indexed tables
Avoid DELETE FROM ...WHERE ...
Huge locking and logging issues
Long rollback if the delete is canceled
Usually faster to
INSERT the records to keep into a non-indexed table
Create index(es) on
the table
Rename the new table to replace the original
Another alternative is to update the row to mark as deleted, then delete later during non
critical time.

10. 9 - Manage statistics manually
Statistics on partitioned tables are maintained for the table as a whole.
Manually update statistics on large fact tables after loading new data.
Manually update statistics after rebuilding index on a partition.
If you regularly update statistics after periodic loads, you may turn off
autostats on that table.
This is important for optimizing queries that may need to read only the newest
data.
Updating statistics on small dimension tables after incremental loads may
also help performance. Use FULLSCAN option on update statistics on
dimension tables for more accurate query plans.

11. 10 - Consider efficient backup strategies
Backing up the entire database may take significant amount of time for a very
large database.
For example, backing up a 2 TB database to a 10-spindle RAID-5 disk on a SAN
may take 2 hours (at the rate 275 MB/sec).
Snapshot backup using SAN technology is a very good option.
Reduce the volume of data to backup regularly.
The filegroups for the historical partitions can be marked as READ ONLY.
Perform a filegroup backup once when a filegroup becomes read-only.
Perform regular backups only on the read / write filegroups.
Note that RESTOREs of the read-only filegroups cannot be performed in
parallel.

12. Reference
MSDN Blogs
SQLCAT