Here are the basic steps that we take, you will have to have your DBA use the p-sql equivalent of the t-sql commands listed. If you are running AIE you will need to make changes on a couple of forms as well. Migrate Database:
1. Create back-up of source Remedy database. 2. Copy database BAK file to the destination server. 3. Restore source database BAK onto destination Remedy database. 4. Change db owner from ARAdmin to SA * exec sp_changedbowner 'sa' 1. Change db owner back to ARAdmin using the following commands: * exec sp_dropuser 'ARAdmin' * exec sp_changedbowner 'ARAdmin' exec sp_defaultdb 'ARAdmin', 'ARSystem' From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Carl Wilson Sent: Wednesday, July 17, 2013 7:54 AM To: [email protected] Subject: Re: Copied prod server to new server - patch weirdness ** Hi, When restoring a DB to another environment (not the original), generally the permissions for "ARAdmin" are removed and need to be re-applied to the DB. These need to be re-instated by the DBA before starting ARS (ensuring the correct password for "ARAdmin" on the target environment is maintained). Another tip is to place the all the other environments (Dev, Test, UAT, etc) Server keys into the Production system. ARS is smart enough to ignore the invalid keys for the other servers but it means you do not have to re-apply when copying databases between environments and they will pick up their respective key when starting. ________________________________ Kind Regards, Carl Wilson From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jason Miller Sent: 17 July 2013 06:32 To: [email protected]<mailto:[email protected]> Subject: Re: Copied prod server to new server - patch weirdness ** Going simple but sometimes overlooked ... Is the DB account AR System is using enable and the password is correct in ar.cfg? With MS SQL I have had similar connection errors after restoring a DB and for whatever reason the DB account was disabled when I looked in SQL. Maybe too many connection attempts with the wrong password locked the account? Jason On Tue, Jul 16, 2013 at 2:50 PM, Sanford, Claire <[email protected]<mailto:[email protected]>> wrote: ** I was working with BMC tech support on a patch issue and they told me the only way we could be sure the patches would not break Production the way they broke Test was to copy Prod to the test server and install the patches. I tried using the Restore Tool from the Communities and it won't see the DB either. It gives me the arerr 90 error. I can't even get the server to see the DB. This has been all consuming for the last week! I keep getting the following error. Any ideas? I checked the tnsnames.ora and set the correct values. My DBA reinstalled the Oracle clients. Included both the 64 and 32 bit. I checked the ar.cfg and armonitor.cfg files. Corrected the server listings there as well. Warning! Failed to connect to the database. Possible causes: Path variable points to incorrect Oracle client tnsnames.ora does not exist or has incorrect connection details Missing 64 bit Oracle client libraries. ITSM 7.6.04 SP2 <- Trying to move to SP4 ARS 7.6.04 SP3 <- Trying to move to SP4 Oracle 11.2.0.3.0 - 64bit Production Win 2008 Server Claire Sanford Information Systems Division Memorial Hermann Healthcare System [email protected]<mailto:[email protected]> _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
