Re: SQL Database Replication

[Elry]

Sorry forgot to add the following:

Lessons Learned:

1) Restoring a 2005 SQL database to a 2008 SQL database may have been
the culprit.
2) Even if your 2008 database is running in 2005 Mode - this will
cause unusual problems.
3) ar.cfg needs to be updated.
4) For some reason the ARAdmin User gets dropped in some cases - so
you have to recreate it.
5) Verify that ARAdmin has the right privileges or it will fail...
5) If you change your ARAdmin password in production, but keep the
default elsewhere - you will have to:
a) Make it consistent across all servers.
b) Hard code it in the ar.cfg File if this is "after the restore".
c) If you hard code any passwords - change it from the System
Console to re-encrypt.

I think these were key to getting the system up and operational.

I hope this will help someone else in the future.


On Jul 21, 2:39 pm, Elry  wrote:
> Thanks Folks...
>
> There were a few issues to address witht the DBA, but once we were
> both on the same page - we got everything up and running.
>
> It was at least comforting to know that others had been successful at
> this endeavour; therefore, all that was needed was a little BST (Blood
> Sweat and Tears)...:)
>
> On Jul 20, 11:20 am, Robert Molenda  wrote:
>
>
>
>
>
> >  We have a complete automated solution utilizing SSIS Scripts which will:
>
> >    1. 7zip the complete "last night full backup" of production
> >    2. FTP the compressed file to the target system (test / dev / etc)
> >    3. Uncompress the remote file
> >    4. shutdown remedy processes
> >    5. restore the database
> >    6. grant User Permissions (Restore removes the permissions for ARAdmin
> >    account)
> >    7. Updates the various remedy tables replacing the server name, etc
> >    (Configurable)
> >    8. Starts up remedy
>
> > This works quite well - including the logging of activities into a remedy
> > table in order to provide timing and alerting on success / failures...
> > The only "issues" are:
>
> >    1. Duration of / and sometimes failure of FTP - The SSIS Script can
> >    detect it can generate error to restart job - but unfortunately the 
> > systems
> >    don't support restartable FTP :(
> >    2. Target DB Size - you are transferring production of XX GB to DEV
> >    where really only foundation data only is needed
> >    3. Target DB Size - the nightly full backups of DEV / Test are now XX GB
> >    4. SQL Performance on DEV / TEST - since the DB is now HUGE - so the SQL
> >    Servers for Performance must be capable of supporting a huge database -
> >    Normally Dev / Test are a shared SQL environment because of the size and
> >    performance requirements
>
> > If you would like more information - please contact me directly
> > Robert Molenda - Principal Consultant - Infosys Technologies
>
> > (Note original message thread deleted because of "maximum size" by the list
> > server caused it to be rejected)
>
> > ___­­
> > 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"

Re: SQL Database Replication

[Elry]

Thanks Folks...

There were a few issues to address witht the DBA, but once we were
both on the same page - we got everything up and running.

It was at least comforting to know that others had been successful at
this endeavour; therefore, all that was needed was a little BST (Blood
Sweat and Tears)...:)


On Jul 20, 11:20 am, Robert Molenda  wrote:
>  We have a complete automated solution utilizing SSIS Scripts which will:
>
>    1. 7zip the complete "last night full backup" of production
>    2. FTP the compressed file to the target system (test / dev / etc)
>    3. Uncompress the remote file
>    4. shutdown remedy processes
>    5. restore the database
>    6. grant User Permissions (Restore removes the permissions for ARAdmin
>    account)
>    7. Updates the various remedy tables replacing the server name, etc
>    (Configurable)
>    8. Starts up remedy
>
> This works quite well - including the logging of activities into a remedy
> table in order to provide timing and alerting on success / failures...
> The only "issues" are:
>
>    1. Duration of / and sometimes failure of FTP - The SSIS Script can
>    detect it can generate error to restart job - but unfortunately the systems
>    don't support restartable FTP :(
>    2. Target DB Size - you are transferring production of XX GB to DEV
>    where really only foundation data only is needed
>    3. Target DB Size - the nightly full backups of DEV / Test are now XX GB
>    4. SQL Performance on DEV / TEST - since the DB is now HUGE - so the SQL
>    Servers for Performance must be capable of supporting a huge database -
>    Normally Dev / Test are a shared SQL environment because of the size and
>    performance requirements
>
> If you would like more information - please contact me directly
> Robert Molenda - Principal Consultant - Infosys Technologies
>
> (Note original message thread deleted because of "maximum size" by the list
> server caused it to be rejected)
>
> ___­
> 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"

Re: SQL Database Replication

[Robert Molenda]

 We have a complete automated solution utilizing SSIS Scripts which will:

   1. 7zip the complete "last night full backup" of production
   2. FTP the compressed file to the target system (test / dev / etc)
   3. Uncompress the remote file
   4. shutdown remedy processes
   5. restore the database
   6. grant User Permissions (Restore removes the permissions for ARAdmin
   account)
   7. Updates the various remedy tables replacing the server name, etc
   (Configurable)
   8. Starts up remedy

This works quite well - including the logging of activities into a remedy
table in order to provide timing and alerting on success / failures...
The only "issues" are:

   1. Duration of / and sometimes failure of FTP - The SSIS Script can
   detect it can generate error to restart job - but unfortunately the systems
   don't support restartable FTP :(
   2. Target DB Size - you are transferring production of XX GB to DEV
   where really only foundation data only is needed
   3. Target DB Size - the nightly full backups of DEV / Test are now XX GB
   4. SQL Performance on DEV / TEST - since the DB is now HUGE - so the SQL
   Servers for Performance must be capable of supporting a huge database -
   Normally Dev / Test are a shared SQL environment because of the size and
   performance requirements

If you would like more information - please contact me directly
Robert Molenda - Principal Consultant - Infosys Technologies

(Note original message thread deleted because of "maximum size" by the list
server caused it to be rejected)

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Re: SQL Database Replication

[Elry]

he SQL database
(ARERR 556)
Thu Jul 15 16:55:57 2010  390600 : Form does not exist on server
(ARERR 303)
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password Change:UpdatePassword`!
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password Change:UpdatePassword`!
Thu Jul 15 16:55:57 2010  390600 : Form does not exist on server
(ARERR 303)
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password
Change:UpdatePasswordErrorHandler
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password
Change:UpdatePasswordErrorHandler
Thu Jul 15 16:55:57 2010  390600 : Form does not exist on server
(ARERR 303)
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password
Change:UpdatePasswordMessage
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password
Change:UpdatePasswordMessage
Thu Jul 15 16:55:57 2010  390600 : Form does not exist on server
(ARERR 303)
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)
Thu Jul 15 16:55:57 2010 User Password Management:RestrictSubmit
Thu Jul 15 16:55:57 2010  390600 : Error in definition for a filter
(ARERR 343)

---

I am currently asking the DBA to make sure permissions on the Sandbox
are the same as the permissions on Production.

Thanks - All.

Time for some sleep - then try again in the Morning.




On Jul 15, 3:13 pm, Guillaume Rheault  wrote:
> Hey Elry,
>
> One more thing that I forgot to mention to you, that is a new feature with 
> ARS 7.5, I believe.
> As you may know, AR Server license keys are stored in the database, not in a 
> file as it used be before.
> However, the new feature in ARS 7.5 is that you can enter ARS licenses for 
> servers for which the Host ID is not the one of the current server.
> When the ARS server starts, it picks the license key that matches its host id.
>
> In our case, we entered the DEV and UA ARS serverlicense keys in production, 
> so when we do the database restore, we don't have to key in the ARS Server 
> license key. Very handy.
>
> Myself and other listers have accomplished this task, so it's doable.
>
> So don't give up, and make sure you document all the issues you run into for 
> your specific environment, create a checklist as I suggested, so the next 
> time it will be smoother.
>
> Guillaume
>
> ____________
> From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on 
> behalf of Elry [elryal...@gmail.com]
> Sent: Thursday, July 15, 2010 2:12 PM
> To: arsl...@arslist.org
> Subject: Re: SQL Database Replication
>
> 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  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  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 di

Re: SQL Database Replication

[Easter, David]

> that is a new feature with ARS 7.5, I believe.

Actually it started in AR System 7.1.00.


-David J. Easter
Sr. Product Manager, Enterprise Service Management
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault
Sent: Thursday, July 15, 2010 12:14 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Database Replication

Hey Elry,

One more thing that I forgot to mention to you, that is a new feature with ARS 
7.5, I believe.
As you may know, AR Server license keys are stored in the database, not in a 
file as it used be before.
However, the new feature in ARS 7.5 is that you can enter ARS licenses for 
servers for which the Host ID is not the one of the current server.
When the ARS server starts, it picks the license key that matches its host id.

In our case, we entered the DEV and UA ARS serverlicense keys in production, so 
when we do the database restore, we don't have to key in the ARS Server license 
key. Very handy.

Myself and other listers have accomplished this task, so it's doable.

So don't give up, and make sure you document all the issues you run into for 
your specific environment, create a checklist as I suggested, so the next time 
it will be smoother.

Guillaume



From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on 
behalf of Elry [elryal...@gmail.com]
Sent: Thursday, July 15, 2010 2:12 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Database Replication

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

Re: SQL Database Replication

[Guillaume Rheault]

Hey Elry,

One more thing that I forgot to mention to you, that is a new feature with ARS 
7.5, I believe.
As you may know, AR Server license keys are stored in the database, not in a 
file as it used be before.
However, the new feature in ARS 7.5 is that you can enter ARS licenses for 
servers for which the Host ID is not the one of the current server.
When the ARS server starts, it picks the license key that matches its host id.

In our case, we entered the DEV and UA ARS serverlicense keys in production, so 
when we do the database restore, we don't have to key in the ARS Server license 
key. Very handy.

Myself and other listers have accomplished this task, so it's doable.

So don't give up, and make sure you document all the issues you run into for 
your specific environment, create a checklist as I suggested, so the next time 
it will be smoother.

Guillaume



From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on 
behalf of Elry [elryal...@gmail.com]
Sent: Thursday, July 15, 2010 2:12 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Database Replication

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

Re: SQL Database Replication

[Frank Caruso]

Sounds like a HOT backup was taken - activity was happening in the database
while the backup was running. Try taking a COLD backup -no users logged on.

On Thu, Jul 15, 2010 at 2:48 PM, Grooms, Frederick W <
frederick.w.gro...@xo.com> wrote:

> Turn on SQL Logging and watch the error log for the Missing data error.
>  When you get one look at the SQL log to see what is being done at that
> time.
>
> I hate to say it but on first glance it seems like your database
> backup-restore/copy was not a complete copy of production.
>
> Fred
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
> arsl...@arslist.org] On Behalf Of Elry
> Sent: Thursday, July 15, 2010 1:12 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: SQL Database Replication
>
> 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  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  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  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 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  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 d

Re: SQL Database Replication

[Grooms, Frederick W]

Turn on SQL Logging and watch the error log for the Missing data error.  When 
you get one look at the SQL log to see what is being done at that time.

I hate to say it but on first glance it seems like your database 
backup-restore/copy was not a complete copy of production.

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Elry
Sent: Thursday, July 15, 2010 1:12 PM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Database Replication

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  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  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  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 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  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&#

Re: SQL Database Replication

[Jason Miller]

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

Re: SQL Database Replication

[Elry]

Agreed...

I am now begining this tedious task of determining if there are any
server references embedded in the workflow and forms that cannot be
displayed.

Thanks Joe.


On Jul 15, 2:38 pm, Joe DeSouza  wrote:
> The only way to check for server references is exporting the definitions and
> looking for server names in those definitions. Everything looks normal viewing
> these objects through the Admin or the Developer tool.. Personally I prefer 
> XML
> definitions as its easier to edit these from XML files and not worrying
> about string lengths and all that good stuff..
>
> Sometimes you cannot blame your developers if server names have still crept 
> in,
> as with some versions of the older Admin tool, there were bugs, where certain
> workflow objects would save the server names instead of making them server
> independent when those objects were created of modified. I have not quite 
> seen a
> pattern on when and how these server names creep in, but did notice that using
> the IP Address as the server name in the Accounts while connecting to the
> server, can cause these kind of issues and would save the IP address instead
> of @ in the database.
>
> Joe
>
> 
> From: Elry 
> To: arsl...@arslist.org
> Sent: Thu, July 15, 2010 11:50:26 AM
> Subject: Re: SQL Database Replication
>
> Thanks Joe...
>
> The application that we are using is not ITSM.  It is a custom application 
> that
> we have built.
>
> All the developers were warned not to hard-code server names, but I have never
> actually checked for this ( I will now).
>
> We are not using AIE or LDAP.
>
> I did not alter the ar.cfg file - shoud we try starting it up with the ar.cfg
> adapted to look like the original?
>
> On Jul 15, 11:44 am, Joe DeSouza  wrote:
>
>
>
>
>
> > Elry,
>
> > One of the reasons answers differ and vary is the configuration. All depends
> on
> > what applications you are using. Does the application have configuration
> > data that hard codes server names like AIE would in its configuration. Some
> > applications store some environment specific information like LDAP server
> names
> > and login credentials. Then there are odd cases where under certain 
> > conditions
> > you get server names or IP Addresses of the server hardcoded into workflow
> such
> > as table fields. Sometimes you need to consider looking up the meta data and
> > make sure you do not have hard coded server name references in workflow.
>
> > So for the most part, yes a simple backup and restore of the database works
> > directly unless you need to tweak some of the application or configuration
> data
> > and meta data to remove hard coded or wrong server references. Also if you
> > choose to replicate the ar.cfg file, make sure you point that file to the
> right
> > database server, or you might end up having a test server point to
> >production...
>
> > Joe
>
> > 
> > From: Elry 
> > To: arsl...@arslist.org
> > Sent: Thu, July 15, 2010 8:46:57 AM
> > 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"- 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"

Re: SQL Database Replication

[Joe DeSouza]

The only way to check for server references is exporting the definitions and 
looking for server names in those definitions. Everything looks normal viewing 
these objects through the Admin or the Developer tool.. Personally I prefer XML 
definitions as its easier to edit these from XML files and not worrying 
about string lengths and all that good stuff..

Sometimes you cannot blame your developers if server names have still crept in, 
as with some versions of the older Admin tool, there were bugs, where certain 
workflow objects would save the server names instead of making them server 
independent when those objects were created of modified. I have not quite seen 
a 
pattern on when and how these server names creep in, but did notice that using 
the IP Address as the server name in the Accounts while connecting to the 
server, can cause these kind of issues and would save the IP address instead 
of @ in the database.

Joe




From: Elry 
To: arslist@ARSLIST.ORG
Sent: Thu, July 15, 2010 11:50:26 AM
Subject: Re: SQL Database Replication

Thanks Joe...

The application that we are using is not ITSM.  It is a custom application that 
we have built.

All the developers were warned not to hard-code server names, but I have never 
actually checked for this ( I will now).

We are not using AIE or LDAP.

I did not alter the ar.cfg file - shoud we try starting it up with the ar.cfg 
adapted to look like the original?



On Jul 15, 11:44 am, Joe DeSouza  wrote:
> Elry,
>
> One of the reasons answers differ and vary is the configuration. All depends 
on
> what applications you are using. Does the application have configuration
> data that hard codes server names like AIE would in its configuration. Some
> applications store some environment specific information like LDAP server 
names
> and login credentials. Then there are odd cases where under certain conditions
> you get server names or IP Addresses of the server hardcoded into workflow 
such
> as table fields. Sometimes you need to consider looking up the meta data and
> make sure you do not have hard coded server name references in workflow.
>
> So for the most part, yes a simple backup and restore of the database works
> directly unless you need to tweak some of the application or configuration 
data
> and meta data to remove hard coded or wrong server references. Also if you
> choose to replicate the ar.cfg file, make sure you point that file to the 
right
> database server, or you might end up having a test server point to 
>production...
>
> Joe
>
> 
> From: Elry 
> To: arsl...@arslist.org
> Sent: Thu, July 15, 2010 8:46:57 AM
> 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 at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Re: SQL Database Replication

[Elry]

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  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  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  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 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  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...
>
> &

Re: SQL Database Replication

[Elry]

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

Re: SQL Database Replication

[LJ LongWing]

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: arslist@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  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 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  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 A

Re: SQL Database Replication

[Elry]

Thanks Joe...

The application that we are using is not ITSM.  It is a custom
application that we have built.

All the developers were warned not to hard-code server names, but I
have never actually checked for this ( I will now).

We are not using AIE or LDAP.

I did not alter the ar.cfg file - shoud we try starting it up with the
ar.cfg adapted to look like the original?



On Jul 15, 11:44 am, Joe DeSouza  wrote:
> Elry,
>
> One of the reasons answers differ and vary is the configuration. All depends 
> on
> what applications you are using. Does the application have configuration
> data that hard codes server names like AIE would in its configuration. Some
> applications store some environment specific information like LDAP server 
> names
> and login credentials. Then there are odd cases where under certain conditions
> you get server names or IP Addresses of the server hardcoded into workflow 
> such
> as table fields. Sometimes you need to consider looking up the meta data and
> make sure you do not have hard coded server name references in workflow.
>
> So for the most part, yes a simple backup and restore of the database works
> directly unless you need to tweak some of the application or configuration 
> data
> and meta data to remove hard coded or wrong server references. Also if you
> choose to replicate the ar.cfg file, make sure you point that file to the 
> right
> database server, or you might end up having a test server point to 
> production...
>
> Joe
>
> 
> From: Elry 
> To: arsl...@arslist.org
> Sent: Thu, July 15, 2010 8:46:57 AM
> 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 at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Re: SQL Database Replication

[Guillaume Rheault]

Well, we don't replicate the ar.cfg file I never had to do that for this 
purpose.

The ar.cfg file is the file where the environment specif information is stored, 
as you know, including the directory structure. So I would leave this file 
untouched.

The only thing that may need to be updated is the SQL server database if it 
different than production (not the database server), and the DB password

Guillaume



From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on 
behalf of Joe DeSouza [joe_rem...@yahoo.com]
Sent: Thursday, July 15, 2010 11:44 AM
To: arslist@ARSLIST.ORG
Subject: Re: SQL Database Replication

**
Elry,

One of the reasons answers differ and vary is the configuration. All depends on 
what applications you are using. Does the application have configuration data 
that hard codes server names like AIE would in its configuration. Some 
applications store some environment specific information like LDAP server names 
and login credentials. Then there are odd cases where under certain conditions 
you get server names or IP Addresses of the server hardcoded into workflow such 
as table fields. Sometimes you need to consider looking up the meta data and 
make sure you do not have hard coded server name references in workflow.

So for the most part, yes a simple backup and restore of the database works 
directly unless you need to tweak some of the application or configuration data 
and meta data to remove hard coded or wrong server references. Also if you 
choose to replicate the ar.cfg file, make sure you point that file to the right 
database server, or you might end up having a test server point to production...

Joe


From: Elry 
To: arslist@ARSLIST.ORG
Sent: Thu, July 15, 2010 8:46:57 AM
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.

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

Re: SQL Database Replication

[Joe DeSouza]

Elry,

One of the reasons answers differ and vary is the configuration. All depends on 
what applications you are using. Does the application have configuration 
data that hard codes server names like AIE would in its configuration. Some 
applications store some environment specific information like LDAP server names 
and login credentials. Then there are odd cases where under certain conditions 
you get server names or IP Addresses of the server hardcoded into workflow such 
as table fields. Sometimes you need to consider looking up the meta data and 
make sure you do not have hard coded server name references in workflow.

So for the most part, yes a simple backup and restore of the database works 
directly unless you need to tweak some of the application or configuration data 
and meta data to remove hard coded or wrong server references. Also if you 
choose to replicate the ar.cfg file, make sure you point that file to the right 
database server, or you might end up having a test server point to production...

Joe





From: Elry 
To: arslist@ARSLIST.ORG
Sent: Thu, July 15, 2010 8:46:57 AM
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 at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
  

Re: SQL Database Replication

[Guillaume Rheault]

I am not that familiar with SQL Server, so I cannot tell you.
In the Oracle world, you simply would drop the schema that ARS uses in the DEV 
database and import the production schema into the DEV database.

Since an Oracle schema is more or less the equivalent of a SQL server database, 
I assume the database that ARS uses in development needs to be dropped, and the 
new one from production restored.

In any case, if you don't have a competent DBA to perform this task, you'll 
have problems.

But if you have an incompetent DBA, you have other problems such as disaster 
recovery and backups

Guillaume


From: Action Request System discussion list(ARSList) [arsl...@arslist.org] on 
behalf of Elry [elryal...@gmail.com]
Sent: Thursday, July 15, 2010 11:36 AM
To: arslist@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  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 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  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).
> > Sp

Re: SQL Database Replication

[Terry Bootsma]

**
Elry:I do this all the time.  It should work well no problems restoring the database and it should come up fine (just that it won't be licensed until you change the license file, change some hard-coded server references (that don't affect startup)) as long as you have the same base SQL-Server setup and are running the same versions of Remedy between the boxesYou got my number if you want to talk further...  :-)Terry
On Jul 15, 2010, Elry  wrote:

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 bethe source of the problem.On Jul 15, 11:30 am, Terry Bootsma  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 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  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

Re: SQL Database Replication

[Elry]

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

Re: SQL Database Replication

[Terry Bootsma]

**
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  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 theARS Service tries to start - this ouput occurs in the arrerror.logLooks like ARMonitor shuts it down with a ARERR 33 AND ARERR 32.Anyone familiar with this On Jul 15, 10:58 am, Guillaume Rheault  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 at www.arslist.orgattend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

_attend WWRUG10 www.wwrug.com  ARSlist: "Where the Answers Are"_

Re: SQL Database Replication

[Elry]

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  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 at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Re: SQL Database Replication

[Guillaume Rheault]

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: arslist@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 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"

Re: SQL Database Replication

[Elry]

Hi Fred...

It would be a one time copy that is repeatable on a 3-6 month cycle
for Staging and Dev.

We would just want to be able to dump real data to make sure that
nothing is missed in Q&A for Testing.

However for reporting it would be a constant sync for about 12 metric
collection tables that have been developed (Migrator will work for
this).



On Jul 15, 9:50 am, "Grooms, Frederick W" 
wrote:
> Is this a one-time copy (or maybe like once a quarter type of thing), or a 
> constant sync.
>
> Fred
>
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:arsl...@arslist.org] On Behalf Of Elry
> Sent: Thursday, July 15, 2010 7:47 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"- 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"

Re: SQL Database Replication

[Grooms, Frederick W]

Is this a one-time copy (or maybe like once a quarter type of thing), or a 
constant sync.

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Elry
Sent: Thursday, July 15, 2010 7:47 AM
To: arslist@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 at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"