Skip to main content
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Source Link

Most of the reports I create aren't run on current data. Most customer's are running reports are yesterday's data. Would your answer change if that was the case?

If that's the case, then you have one more possible option:
Instead of running your queries on the production database and messing around with locks and NOLOCK, you could run your reports from a copy of the production database.

You can set it up so it's automatically restored from a backup each nightit's automatically restored from a backup each night.
Apparently your reports are running on servers on customer's sites, so I don't know if setting this up would be a viable solution for you.
(but then again...they should have backups anyway, so all you need is some server space to restore them)

I'm an in-house developer, so this is easier for me because I have full control over the servers and databases.

You can do this at least for the reports that only need data from yesterday and older. Maybe some reports will have to stay on the production database, but at least you move some of the load to another database (or even better, another server).

I have the same situation at work as well:
We are using a production database copy like this for nearly all reporting stuff, but there are a few queries that require today's data.

Most of the reports I create aren't run on current data. Most customer's are running reports are yesterday's data. Would your answer change if that was the case?

If that's the case, then you have one more possible option:
Instead of running your queries on the production database and messing around with locks and NOLOCK, you could run your reports from a copy of the production database.

You can set it up so it's automatically restored from a backup each night.
Apparently your reports are running on servers on customer's sites, so I don't know if setting this up would be a viable solution for you.
(but then again...they should have backups anyway, so all you need is some server space to restore them)

I'm an in-house developer, so this is easier for me because I have full control over the servers and databases.

You can do this at least for the reports that only need data from yesterday and older. Maybe some reports will have to stay on the production database, but at least you move some of the load to another database (or even better, another server).

I have the same situation at work as well:
We are using a production database copy like this for nearly all reporting stuff, but there are a few queries that require today's data.

Most of the reports I create aren't run on current data. Most customer's are running reports are yesterday's data. Would your answer change if that was the case?

If that's the case, then you have one more possible option:
Instead of running your queries on the production database and messing around with locks and NOLOCK, you could run your reports from a copy of the production database.

You can set it up so it's automatically restored from a backup each night.
Apparently your reports are running on servers on customer's sites, so I don't know if setting this up would be a viable solution for you.
(but then again...they should have backups anyway, so all you need is some server space to restore them)

I'm an in-house developer, so this is easier for me because I have full control over the servers and databases.

You can do this at least for the reports that only need data from yesterday and older. Maybe some reports will have to stay on the production database, but at least you move some of the load to another database (or even better, another server).

I have the same situation at work as well:
We are using a production database copy like this for nearly all reporting stuff, but there are a few queries that require today's data.

Source Link

Most of the reports I create aren't run on current data. Most customer's are running reports are yesterday's data. Would your answer change if that was the case?

If that's the case, then you have one more possible option:
Instead of running your queries on the production database and messing around with locks and NOLOCK, you could run your reports from a copy of the production database.

You can set it up so it's automatically restored from a backup each night.
Apparently your reports are running on servers on customer's sites, so I don't know if setting this up would be a viable solution for you.
(but then again...they should have backups anyway, so all you need is some server space to restore them)

I'm an in-house developer, so this is easier for me because I have full control over the servers and databases.

You can do this at least for the reports that only need data from yesterday and older. Maybe some reports will have to stay on the production database, but at least you move some of the load to another database (or even better, another server).

I have the same situation at work as well:
We are using a production database copy like this for nearly all reporting stuff, but there are a few queries that require today's data.