We used to have this type of config on a reporting server before. One AR server was updated weekly (SQL restore) and the other monthly.
I our case there were only read actions happening. The server that it was on was not a very wow machine (2 x 2ghx CPU, 4 gb RAM) and it handled it. At the time our DB was at it's largest 80 gb. We used a 3rd party app as a scheduler which called Crystal reports. We have long since gone the business objects route so have broken the multi AR server. What are you looking at using your server for? Is the server the app and db server altogether? What DB sizes are you looking at? You can always put the screws on at db level to use certain cpu's or only a limited amount or RAM (depending on the functions). Kind Regards, Basil -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Icarus4 Sent: 12 September 2008 15:05 To: [email protected] Subject: Multiple Instance of ARS 6.3 on Shared database Hello listers, I'm considering installing multiple instance of ARS 6.3 on the same box. Instances will share the same database. Anyone did a performance comparison between single and multiple instances? Does it bring a better usage of the server resources? Thanks for sharing. -- View this message in context: http://www.nabble.com/Multiple-Instance-of-ARS-6.3-on-Shared-database-tp 19414834p19414834.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ________________________________________________________________________________________ The information in this e-mail is confidential and is intended solely for the addressee. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform the sender immediately and destroy the original. Siemens Limited and/or its subsidiaries accepts no liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from access to this message and any files or links that are attached hereto. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
