This is my first reply to a topic on SQLServerCentral. I have been a dba for 10 years. Sometimes I feel that I do not have the knowledge you all have but, hey, I have been able to handle teraoctet databases with million rows, so maybe I am doing something right, no?

I definitely have a point of view on this topic. working for a telecommunication company, handling their SQL servers, I feel I might have a point.

My point is very simple, keep the retention period as low as possible on a production environment, dealing with transactional databases.

We can talk about indexing, defragmentation, vertical partitioning, you name it.... All good things to do, I accept that.

But one of the thing that will not change is:

1. Querying tables, especially with table scans, is so much faster with the fewest rows

2. Maintenance on those tables and in particular reindexing is so much faster

3. Disruption of service is almost nothing if it happens

4. Invasive heavy maintenance DB tasks are not as important

a. backup strategies are faster to implement and execute (especially compression files)

b. restore strategies are faster to implement

c. DW extraction is faster to implement and execute

d. High availability strategies (both load balancing and failover) are faster to implement

I think Dba should focus more on managing data and not databases or servers, mainly because the data is more important that the recipient of it.

Then when all data management strategies (purging, reindexing, backuping, extracting) are done, we can focus on optimizing the rest of it.

This is my experience with large databases in telecommunication companies.

All industries are different but Dba, with this approach can clearly synch business needs with a proper approach to the data.