June 3, 2009 at 2:29 pm
Hi all just wanted to lay out my rough plan for a reporting db and see if anyone see any issues with it. Thanks in advance for any input.
System: Clustered Active\Active with one side of cluster running PeopleSoft Finance and the other side running PeopleSoft HRCS (HR and Student). Both indentical top end physical machines with 8 super speedy processors, 8GB of ram (probably will add more), Windows 2003 server 64 bit, with a nice fast SAN for storage.
The Senior network dude and I agree on a potential solution but I lack a similar devel environment to test the effects of replication.
In short:
Use replication to populate two reporting databases, one for Finance one for HRCS using a distributer that is on a seperate machine to lower overhead there. The two reporting databases will be on the SAME cluster as production but will be on a seperate lun on the SAN.
The SAME part is what has my boss worried about degrading performance on prod. The reporting databases will be on the side of the cluster that runs Finance which and does not have any significant load on it (as long as there is no failover :-D). The server is just so beefy and powerful I feel its a waste to offload the reporting db's to another non clustered server (cause we don't have the bucks for another one).
To me I/O is the biggest consideration but this is mitigated having a seperate lun and there is so much processing power and the ability to ramp up as much RAM I don't see any real issues.
But the lack of a good testing enviro has me scared.:unsure:
Any comments?
June 5, 2009 at 2:43 pm
Let me check my understanding of the described scenario.
There is an OLTP database happily living in a cluster which for the purpose of this exercise I would call system-a.
So, the plan a Network person and a Database person come with to aliviate preformance pressure on system-a is to create other two -Reporting - databases in the very same system-a and add on top of it replication overhead. Is that correct? :doze:
I would include a Systems person and an Storage person in the discussions.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.June 8, 2009 at 8:37 am
PaulB (6/5/2009)
Let me check my understanding of the described scenario.There is an OLTP database happily living in a cluster which for the purpose of this exercise I would call system-a.
So, the plan a Network person and a Database person come with to aliviate preformance pressure on system-a is to create other two -Reporting - databases in the very same system-a and add on top of it replication overhead. Is that correct? :doze:
I would include a Systems person and an Storage person in the discussions.
The thought was having it on a different lun it would not affect the production databases (the CPU and RAM usage sits at about 5% on average). I am unsure of how much overhead replication incurs.
June 9, 2009 at 6:01 pm
Hi,
You're only going to get noticable gains if you see performance degradation (blocking, locking, I/O slowdowns, other waitstats) during the times where your reports run. Depending on the situation, you might be wasting time/effort setting this stuff up if it will not have user impact. Time may be better spent tuning the SQLs.
Are we talking SQRs? Business Objects reports?
Donger
June 10, 2009 at 11:50 am
Mostly sqr's. You are right, at the moment there is no real need for a reporting environment, its when HRCS is implemented in the fall that there should be significant usage. HRCS will be on one side of the cluster with Finance on the other.
It seems as long as the data in the reporting enviro is 24 hours old or less the clients will be happy so I might just set up log shipping to another server and be done with it.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply