Wake up Bhaskar! No more sleeping at the desk (or perhaps I was simply trying to multi-task across too many things at once)! Sorry, Alexis.
I explained why a .jnl (journal) file can grow fast, but not why a .dat (database) file can grow fast. The only way for a database file to grow is if it has data put into it. A mupip integ -full will tell you how much space each global takes, and a mupip journal -extract will tell you which processes put them there. Apropos Greg's question, yes, with the GT.M journal file you can trace each update back to a specific user id, process and (approximate) time. And it's not just in theory - folklore has it (I don't know details, and it was before my time that it is supposed to have happened, so it is possible that this is an urban legend) that this information was used to identify a bank employee with his hand in the cookie jar. -- Bhaskar -----Original Message----- From: [EMAIL PROTECTED] on behalf of Greg Kreis Sent: Wed 9/8/2004 6:46 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [Hardhats-members] DAT file keeps growing up So, in theory, if you keep a table of user IDs and process IDs with date and time, you could trace back journal entries to a specific user on GT.M? Does anyone know if Cache's journals contain that much information? K.S. Bhaskar wrote: >Alexis -- > >Remember that the journal file contains information on all sets and >kills, as well as before images of modified blocks. [A quick read of >the chapter on journaling in the Administration and Operations manual as >well as Technical Bulletin 5-025 on the Mupip Set Journal command >(http://sourceforge.net/docman/display_doc.php?docid=11357&group_id=11026) may be in >order.] > >The mupip journal -extract command can be used to tell you exactly which >process made what updates. > >My guess is that the bulk of the information is before images - since >you are presumably not making updates at a fast rate, every time that a >block is modified during an epoch, GT.M will write a before image of >that block. For development purposes, you can use the epoch_interval >command of mupip set -journal to be something very large, such as 3600 >(once an hour) or even 86400 (once a day). > >Note that a large journal file is nothing to be concerned about. If you >want to get rid of it, backup the database using the mupip backup >command with the -newjnlfiles=noprevlink option. Once the backup >completes, you can delete the old generation journal file, since it will >no longer be needed for recovery from a system crash. > >-- Bhaskar > >On Wed, 2004-09-08 at 14:45, "Christian Alexis Diez Ocaña" wrote: > > >>Hi, >> >> >> >>I’m running SemiViva 0.4 over GT.M. >> >>Last week my mumps.dat file was 271M, today it is 769M ! >> >>I just added a few patients and a few new persons, and I can’t figure >>out the reason for such growth. >> >>Is there a way to identify what process is making the dat file larger? >>And/Or which files (within Vista) are growing up ? >> >> >> >>Thanks, >> >>Alexis *************************************************************************** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *************************************************************************** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel.
<<winmail.dat>>
