Thanks Terry... Just spoke to the DBA - what he actually did was:
1) Made a backup copy of Production. 2) Restored the backup copy to the Sandbox. This appears to be quite different from replication - could this be the source of the problem. On Jul 15, 11:30 am, Terry Bootsma <tboot...@objectpath.com> wrote: > ** Elry: > One thing to consider is that when you replicate from server A to server B, > the replicated database may not be in an "active" state. You may have to > take it out of this state to actually start Remedy and have it connect to > it... have you tried this? > Terry > > On Jul 15, 2010,Elry<elryal...@gmail.com> wrote: > > 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 atwww.arslist.org > attend wwrug10www.wwrug.comARSlist: "Where the Answers Are" > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
