Performance Implications of Having Separate Databases for OLTP and Reporting

I have always heard that having a separate reporting database from your OLTP database is a good practice for reasons of performance.

In my particular application, we have perhaps 1,000 concurrent users.  Each user is continuously adding new records to tables.
There are very few updates to records (almost none), and very few reads.  When updates or reads occur, they occur to single
records belonging to that user, executed by that user.  In addition we have perhaps 10 admin people that periodically run
reports on big segments of the data (perhaps the last 3 months of records).

We have thought about using replication to copy data to another computer, and then have the reports run on that computer.
I have several questions concerning this:

1) What performance implications are there in this strategy (as opposed to say, adding more CPUs to the main machine)?
Could you give a brief description of how performance is enhanced (if it is) by separating OLTP from reporting.

2) Do you have any real world test cases or scenarios where this was done?  What were the effects?  What were some of
the unintended consequences or negative effects of the move?
Who is Participating?
Jay ToopsConnect With a Mentor Commented:
a) No matter how many cpu's you add you risk locking the tables while reports are
b) cpu's ARE not MEMORY .. most servers are limited to how much they can slurp into
RAM for performance .. so there would be severe performance drop off of your OLTP
server just as SOON as you ran report a that slurped 3 months of data into the current workspace to do your report
c) typically users want to run reports about at the same time your PEAK sever load happens and this is bad.. especially when running more than one report ...

a) this is not MOVING data to a reporting server is copying or replicating
there is some overhead caused by forwarding the txns to the server but usually ppl
do this at night and must ppl generating reports don't mind if the data is a few hours out of date anyway.
b) EVERY major company that was doing any kind of OLTP i have ever worked for
has a reporting server.   the only exception to this is on where they don't have  the
mony to buy one... then they run there reports at night and Cache the results.

on my mind if a daily report generation is acceptible  then building reports during nightly off peak hours and storing for daily consuption in a separate database is just what is needed.

Adding CPU(s) for nightly job building reports is very good idea, yes. Adding RAM for daily OLTP activity may be useful, but in terms of report this is not really needed. SQL Server memory needs are very reasonable, unless of course you prefer complete 64 bit solution with the database living in memory. The "real life" reports are cpu hungry.

-- cheers
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.