Hi Guillaume... We just gave it a try this morning and got the following error:
Incorrect format in the definition file (ARERR 402). This is when the ARS Service tries to start - this ouput occurs in the arrerror.log Looks like ARMonitor shuts it down with a ARERR 33 AND ARERR 32. Anyone familiar with this .... On Jul 15, 10:58 am, Guillaume Rheault <guilla...@dcshq.com> wrote: > Elry, > > I believe option A is the best, because you will get all the data from > production on your development and test environments. This is a huge plus. > There are a few things that you would need to change once the database is > overwritten, such as updating the ARS and ITSM licenses assigend to users > (assuming your fixed and floating counts are different from production to dev > and UAT), and disabling the outgoing mailbox from your dev and UAT > environments, to make sure no email goes out accidentally. > > Keep in mind that BMC (well really the old Remedy) architected ARS from its > inception do perform this very task, so it's definitely doable. There were > some bugs in older ARS versions where the server references were hardcoded, > but this is not the case with latest versions (i.e. 7.x and 6.3, I believe). > > You may find some sporadic server references in entries in configuration > forms in ITSM, but BMC is working towards making sure there are no server > references in the next version. > It's only a matter of keeping for yourself a checklist of things to do after > the DB overwrite. > > I suggest creating a ticket with BMC support specifying your ITSM version and > patch, so BMC can tell you where, if any, server references are found in your > ITSM version. > > I think you'll find this the best option once you get going. > > Guillaume > > ________________________________________ > From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on > behalf of Elry [elryal...@gmail.com] > Sent: Thursday, July 15, 2010 8:46 AM > To: arsl...@arslist.org > Subject: SQL Database Replication > > Hi Folks... > > I am going to ask this question again - because I have never seen a > definitive answer. > > Here is what we have: > > 1) Independent SQL Database Tier (2005). > 2) ARSystem Application Tier (7.5 Patch 2). > 3) Mid-tier (7.5 Patch 2). > > Environments: > > 1) Sandbox > 2) Development > 3) Staging > 4) Production > 5) Reporting/Archiving (to be deployed). > > What we need to do is the following: > > 1) Update the Staging and Development environments with data from > production > 2) Replicate the Production database to our new Reporting/Archiving > environment. > > Options being considered: > > A) Database Replication. > B) BMC Remedy Migrator. > C) DSO. > > We understand and know how to use options B) and C). We are looking > for feedback from anyone who is successfully using option A). > Specifically... > > 1) What type of replication. > 2) Are there configuration paramaters that are retained at the > database level that need to be changed. > 3) Are there any considerations for ar.cfg. > > I have never seen a white paper on database replication ( I understand > that this method is unsupported). > > Any feedback would be greatly appreciated. > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
