To All,
Brian is correct, there are times when any file can get out of synch in
Netbase. The really good news is that if you also get Quest's training when
you buy your primary and shadow licenses, they teach you how to fix those
little details... Granted, the upfront costs for two copies, and maintenance
for the copies is not cheap, but when you compare that to the cost of
downtime and re-creating your data, well that is a decision best left to you
and your management...
Chuck Ciesinski
----- Original Message -----
From: "Brian Donaldson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, October 11, 2004 12:41 PM
Subject: Re: [HP3000-L] [MANMAN:4799] IMAGE logging "problems"
> Yes, it works great until the TurboIMAGE data bases get out of sync....
>
> And Netbase Shadowing requires two HP3000's. A rather hefty expense if
> your shop has only one box.....
>
> Brian Donaldson.
>
> On Mon, 11 Oct 2004 10:29:03 -0400, Wyell Grunwald
> <[log in to unmask]> wrote:
>
> >I would like to add that we used Quest Netbase in Indiana, and it is
> >wonderful software. Extremely stable and well written.
> >
> >Wyell Grunwald
> >
> >>>> John Saylor <[log in to unmask]> Monday, October 11, 2004
> >10:23:15 AM >>>
> >After turning on logging are you finding recourses tight? If so
> >consider your options carefully... Image logging can add additional
> >overhead cycles you may not be planning on.
> >
> >There is a configuration parameter for Image logging to create and
> >build a new log file based on reaching the size limit. The smaller the
> >size the more frequent the file is built. Image Recovery is cumbersome
> >and time consuming and does not always yield the desired results.
> >
> >Quest Software has a Image replication tool called NetBase Shadowing
> >that many MANMAN customers use in the industry for high-availability,
> >system offloading of Cognos QUIZ reporting. Additionally, this tools
> >works with BridgeWare that provides for delta changes passed to data
> >warehousing/data marts or migration to new platforms.
> >
> >If you are available today I would like to discuss other options open
> >to you if you plan to homestead for a few more years or even migrate off
> >the 3K platform. We are are running a Q4 special that will yield you and
> >your company significant savings. Additionally, we have other secondary
> >options that may yield the same benefit you are looking for.
> >
> >Regards,
> >
> >John Saylor
> >Director of Specialized Markets
> >
> >Quest Software
> >8001 Irvine Center Drive
> >Irvine, CA 92618
> >Tel: 949.754.8422
> >Toll Free: 800.306.9329 x8422
> >Fax: 949.754.1801
> >Cell: 949.933.8422
> >www.quest.com <http://www.quest.com/>
> >-----Original Message-----
> >From: Simpkins, Terry [mailto:[log in to unmask]]
> >Sent: Monday, October 11, 2004 6:45 AM
> >To: [log in to unmask]; manman-L (manman-l)
> >Subject: [MANMAN:4799] IMAGE logging "problems"
> >
> >
> >
> >We have recently turned on IMAGE logging for several MANMAN databases.
> >
> >This was done to provide an audit trail in order to satisfy
> >Sarbanes-Oxley requirements.
> > (treat this as a given, I have lost the battle with the auditors)
> >
> >To try and minimize the impact on nightly processing, we decided to
> >"turn off" logging right before our nightly MRP
> >run, and then turn it back on right after the MRP run. The objectives:
> >
> >- minimize the processing resource impact
> >- don't create 'lots' of IMAGE log file records that have no value
> >
> >We seemed to have "out smarted" ourselves because every night we have
> >at least one logging process that doesn't get
> >restarted correctly. This means the users are unable to access the
> >application until ISIT finds the missing logid and "restarts"
> >
> >that logging process.
> >
> >There are two ways to "turn off" logging during the nightly jobs:
> >- issue a LOGGING logid, STOP command for the DB in question
> >- use DBUTIL to disable the DB for logging
> >
> >Then a soon as the nightly processing is complete, just "reverse" the
> >action taken to turn off logging.
> >Our problem seems to be that we have something "get in the way" of the
> >restart process, and prevent a logging process from starting.
> >
> >We have 4 instances of 13 logging processes that must be manipulated
> >this way. Various interdependancies make the sequencing quite
> >
> >tricky, and susceptible to problems.
> >
> >How have others solved this sort of problem. My inclination is to
> >simply turn on logging and leave it on, and stop worrying about the
> >
> >"wasted CPU cycles" and "unneeded logfile records" created during the
> >MRP run. I'm tired of trouble shooting every morning.
> >
> >*****************************
> >Terry W. Simpkins
> >Director ISIT
> >Measurement Specialties
> >757-766-4278
> >[log in to unmask]
> >*****************************
> >
> >* To join/leave the list, search archives, change list settings, *
> >* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
> >
> >IMPORTANT WARNING: The information in this message (and the documents
> attached to it, if any) is confidential and may be legally privileged. It
> is intended solely for the addressee. Access to this message by anyone
else
> is unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken, or omitted to be taken, in
> reliance on it is prohibited and may be unlawful. If you have received
this
> message in error, please delete all electronic copies of this message (and
> the documents attached to it, if any), destroy any hard copies you may
have
> created and notify me immediately by replying to this email. Thank you.
> >
> >* To join/leave the list, search archives, change list settings, *
> >* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
