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 <elryal...@gmail.com> 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 <robert.mole...@gmail.com> 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"
