In the Stack Exchange Data Explorer each Sunday all databases are dropped and recreated one by one with this stored procedure.

For each database the script starts with (paraphrased) for example Dba.StackExchange:

Create Database [dba_Temp]
          ON  PRIMARY (NAME = 'dba', FILENAME = 'dba.mdf')
          LOG ON (NAME = 'dba_log', FILENAME = 'dba_log.ldf')

Then it does for the tables an select into from a table that is on a linked server, for example for the Users table (paraphrased again):

Select * Into [dba_Temp].[dbo].[Users] From [CO_SQL03].[StackExchange.Dba].[dbo].[vExportUsers];

At the end the current StackExchange.Dba database is dropped and the dba_temp is renamed to StackExchange.Dba

Alter Database [dba_temp] Modify Name = [StackExchange.Dba]

Rinse repeat for the other 349 databases.

I'm interested in how long it took for each database to get refreshed, for example in a query like this so we can provide better support for questions like I'm getting an “Invalid object name 'StackExchange.Cstheory.Meta_Temp.dbo.posts'.” when executing a cross-site query in SEDE

The output of sys.databases for a restored database baffles me a bit. I've been using this query.

The create_date for the StackOverflow database is 2020-05-24 10:36:19 but that isn't the creation date, that is the last action that took place. That is also confirmed by looking at the create_date of Tables. The first table (Users) is created on 2020-05-24 05:49:59, the last table on 2020-05-24 10:31:07. The last statement in the refresh script is the creation of the database principal. Its create date is 2020-05-24 10:36:19. That matches the create_date of the database.

I'll accept that I can always use the workaround to investigate to create_data of the objects in the database to find the closest possible date to the create_data of the database.

Is there any other system catalog view I could query to get the actual create_date of the database in the context of the Stack Exchange Data Explorer? That last part might be a frustrating limitation as the SEDE instance seems pretty hardened. Probably because I knocked a bit too hard on the door now and then. For example sys.database_files does return rows but the SVC_SEDE user doesn't have permission on sys.master_files. None of those views have a create_date (except that the date and time is encoded in the database filename, uuggghhh) so even if that user had access it wouldn't have solved my problem.

Which system catalog view has the create_date of a database which name was modified? Or an alternative reliable method if such view doesn't exist.


Which system catalog view has the create_date of a database which name was modified? Or an alternative reliable method if such view doesn't exist.

You're correct in your assessment of create_date in sys.databases, which is confirmed by the documentation:

Date the database was created or renamed.

So the create_date is the ideal value to use as the end time of the refresh process, being that the rename is the final step.

That being said, given the restrictions in place here I don't think you'll find any more accurate of a start time than the timestamp on the first table.

So the unsatisfying answer is you're as close as you're going to get, I think.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.