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 < [email protected]> 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: > [email protected]] On Behalf Of Elry > Sent: Thursday, July 15, 2010 1:12 PM > To: [email protected] > 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 <[email protected]> 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 <[email protected]> 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:[email protected]] On Behalf Of Elry > > > Sent: Thursday, July 15, 2010 9:36 AM > > > To: [email protected] > > > 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 <[email protected]> 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<[email protected]> wrote: > > > > > > Hi Guillaume... > > > > We just gave it a try this morning and got the following error: > > > > Incorrect format in the definition file (ARERR 402). This is when the > > > > ARS Service tries to start - this ouput occurs in the arrerror.log > > > > Looks like ARMonitor shuts it down with a ARERR 33 AND ARERR 32. > > > > Anyone familiar with this .... > > > > On Jul 15, 10:58 am, Guillaume Rheault <[email protected]> wrote: > > > > > Elry, > > > > > > > I believe option A is the best, because you will get all the data > from > > > production on your development and test environments. This is a huge > plus. > > > > > There are a few things that you would need to change once the > database > > > is overwritten, such as updating the ARS and ITSM licenses assigend to > users > > > (assuming your fixed and floating counts are different from production > to > > > dev and UAT), and disabling the outgoing mailbox from your dev and UAT > > > environments, to make sure no email goes out accidentally. > > > > > > > Keep in mind that BMC (well really the old Remedy) architected ARS > from > > > its inception do perform this very task, so it's definitely doable. > There > > > were some bugs in older ARS versions where the server references were > > > hardcoded, but this is not the case with latest versions (i.e. 7.x and > 6.3, > > > I believe). > > > > > > > You may find some sporadic server references in entries in > configuration > > > forms in ITSM, but BMC is working towards making sure there are no > server > > > references in the next version. > > > > > It's only a matter of keeping for yourself a checklist of things to > do > > > after the DB overwrite. > > > > > > > I suggest creating a ticket with BMC support specifying your ITSM > > > version and patch, so BMC can tell you where, if any, server references > are > > > found in your ITSM version. > > > > > > > I think you'll find this the best option once you get going. > > > > > > > Guillaume > > > > > > > ________________________________________ > > > > > From: Action Request System discussion list(ARSList) > > > [[email protected]] on behalf of Elry [[email protected]] > > > > > Sent: Thursday, July 15, 2010 8:46 AM > > > > > To:[email protected] <to%[email protected]> > > > > > Subject: SQL Database Replication > > > > > > > Hi Folks... > > > > > > > I am going to ask this question again - because I have never seen a > > > > > definitive answer. > > > > > > > Here is what we have: > > > > > > > 1) Independent SQL Database Tier (2005). > > > > > 2) ARSystem Application Tier (7.5 Patch 2). > > > > > 3) Mid-tier (7.5 Patch 2). > > > > > > > Environments: > > > > > > > 1) Sandbox > > > > > 2) Development > > > > > 3) Staging > > > > > 4) Production > > > > > 5) Reporting/Archiving (to be deployed). > > > > > > > What we need to do is the following: > > > > > > > 1) Update the Staging and Development environments with data from > > > > > production > > > > > 2) Replicate the Production database to our new Reporting/Archiving > > > > > environment. > > > > > > > Options being considered: > > > > > > > A) Database Replication. > > > > > B) BMC Remedy Migrator. > > > > > C) DSO. > > > > > > > We understand and know how to use options B) and C). We are > looking > > > > > for feedback from anyone who is successfully using option A). > > > > > Specifically... > > > > > > > 1) What type of replication. > > > > > 2) Are there configuration paramaters that are retained at the > > > > > database level that need to be changed. > > > > > 3) Are there any considerations for ar.cfg. > > > > > > > I have never seen a white paper on database replication ( I > understand > > > > > that this method is unsupported). > > > > > > > Any feedback would be greatly appreciated. > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives 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"
