Solved

Performance Implications of Having Separate Databases for OLTP and Reporting

Posted on 2004-09-16
2
360 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 500 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

Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
encrypt SQL Server 2008 port 1433 3 41
Using Sum with Case When within a query 9 42
Need more granular date groupings 4 42
SQL: Transformation or Pivot 3 29
This article shows gives you an overview on SQL Server 2016 row level security. You will also get to know the usages of row-level-security and how it works
Recently we ran in to an issue while running some SQL jobs where we were trying to process the cubes.  We got an error saying failure stating 'NT SERVICE\SQLSERVERAGENT does not have access to Analysis Services. So this is a way to automate that wit…
Familiarize people with the process of retrieving data from SQL Server using an Access pass-thru query. Microsoft Access is a very powerful client/server development tool. One of the ways that you can retrieve data from a SQL Server is by using a pa…
Viewers will learn how to use the SELECT statement in SQL to return specific rows and columns, with various degrees of sorting and limits in place.

738 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