?
Solved

Performance Implications of Having Separate Databases for OLTP and Reporting

Posted on 2004-09-16
2
Medium Priority
?
364 Views
Last Modified: 2006-11-17
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?
0
Comment
Question by:rogerbush8
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 10

Accepted Solution

by:
Jay Toops earned 1500 total points
ID: 12078959
1)
a) No matter how many cpu's you add you risk locking the tables while reports are
running..
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 ...

2)
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.


JAY
0
 
LVL 9

Expert Comment

by:miron
ID: 12079554
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
0

Featured Post

Microsoft Certification Exam 74-409

VeeamĀ® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

JSON is being used more and more, besides XML, and you surely wanted to parse the data out into SQL instead of doing it in some Javascript. The below function in SQL Server can do the job for you, returning a quick table with the parsed data.
In part one, we reviewed the prerequisites required for installing SQL Server vNext. In this part we will explore how to install Microsoft's SQL Server on Ubuntu 16.04.
Via a live example, show how to shrink a transaction log file down to a reasonable size.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question