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 <[email protected]> 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 <[email protected]> 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) [[email protected]] on behalf of Elry [[email protected]]
> Sent: Thursday, July 15, 2010 8:46 AM
> To: [email protected]
> 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"
