Hi Guys... Thanks for all the responses so far.
Guillame: I am checking the ar.cfg file right now and correcting a few discrepancies (i.e. the ARAdmin password in production is not the default). LJ: I agree with Oracle last year - we were able to drop and attach database instances without a "hitch". Right now - it looks like it is probably the differences with the ar.cfg that might be the issue. On Jul 15, 12:03 pm, LJ LongWing <lj.longw...@gmail.com> wrote: > Elry, > This is how we manage our refreshes of Dev/Test, I can let you know that for > our custom application, that function works just fine. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > > [mailto:arsl...@arslist.org] On Behalf Of Elry > Sent: Thursday, July 15, 2010 9:36 AM > To: arsl...@arslist.org > Subject: Re: SQL Database Replication > > 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 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"- Hide quoted text > - > > - Show quoted text - _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
