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
> > > > 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"
