Hi Elry, We have successfully restored backups of 7.5 to other similar environments a few times without any problems.
As for the problems you are running into, we have never seen anything like it. If the meta data checks out ok at the DB level and ARS is the same versions on the two servers my only guesses are: 1) A db permissions issue. Is ARAdmin the owner of the ARSystem db? 2) There is bad server name resolution somewhere. Maybe there is a server reference that was missed in a config file? Maybe the server doesn't completely know itself as the name you are connecting to (IP-Name parameter). Using WUT and Dev Studio, are you connecting to the server as the Server-Name parameter specified in the ar.cfg or a different DNS alias? There hasn't been much discussion about replicating the 12 tables for reporting. We had a situation where we couldn' t update some home grown desktop apps that hooked into our production server (every PC in our environment connects to Remedy db to get config data when it boots) to point to our new server by the time we were going live. We used MS SQL db replication (2008 -> 2005) to keep a few tables in the old db synchronized real time. I was very happy with the reliability and performance. Jason On Thu, Jul 15, 2010 at 11:12 AM, Elry <elryal...@gmail.com> wrote: > Well... > > We were able to get the system up and running, but I noticed that > there are some odd things: > > 1) All structures and data appear to be available at the database > level. > 2) Server Information had no data. > 3) User form cannot be pulled up in the User Tool/ Dev Studio. > 4) Forms that are large (300 + fields) cannot be pulled up in the User > Tool/ Dev Studio. > 5) ARERR 556 Missing data in the SQL Database is "littered" throughout > the arerror.log for forms and workflow. > > This begs the question: Has anyone out there had any such experience > with 7.5???? > > > > > On Jul 15, 12:20 pm, Elry <elryal...@gmail.com> wrote: > > 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 <to%3aarsl...@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 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
