MMRX tool?

[Caroline Couture]

Hi Folks!

We have a new server person on-board and he wants to run the MMRX tool on a
regular basis via a script.

I'm nervous about running a tool via script that can "repair" a MM database.

What are folks experiences with this, if any? My inclination is to run the tool
manually as I have always done.

We are running MM 8.5.6 on server 2003 with windows XP clients. We are also
connected to the central Meeting Maker hub for our University.

What say all?

Thanks!
Caroline
--
College House Computing
3702 Spruce St.
215.573.3887
ITSS for DuBois

"Fairy Tales are more than true; not because they tell us that dragons exist,
but because they tell us that dragons can be beaten." -- G. K. Chesterton


* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson]

At 04:07 PM 5/1/2007 -0400, Caroline Couture wrote:
>Hi Folks!
>
>We have a new server person on-board and he wants to run the MMRX tool on a
>regular basis via a script.

         There was a time when I thought that might be advisable,
except it took hours
         to run, with a judgement call between each run, and it's
clearly intended not to
         be run from a script but rather as an interactive tool.

         But the last time I ran it was before migrating from v7.5 to
v8.5 in June of 2005.
         And indeed it took several hours on our MM databases to
clean down to zero errors.

         We then migrated to v8.5, with all the hassles of that, and
never ran MMRX again until
         March of this year (nearly 2 full years), prior to doing an
experimental EXPORT so some
         folks could experiment with the export file being imported
into Oracle Calendar.

         I was ASTONISHED.   After 2 years on v8.5, the MMRX cleanups
took less than TWENTY
         MINUTES to get to zero errors.   That's three databases (two
servers and a hub) with 400
         users on one server and 30 on another.

         So maybe the desire to run MMRX regularly is
misplaced?   They've clearly done a better
         job in the v8.x days with preventing DB corruptions and live
recoveries than prior versions
         had.

         "Never Underestimate the bandwidth of a station wagon full
of mag tapes"
         J.Lance Wilkinson
("Lance")                     InterNet:  Lance.Wilkinson@...
         Systems Design Specialist -
Lead                AT&T:      [phone]
         Digital Library
Technologies                    FAX:       [phone]
         E3 Paterno Library                              "I'd rather
be dancing..."
         Penn State University                   A host is a host
from coast to coast,
         University Park, PA 16802               And no one will talk
to a host that's close
         <postmaster@...>            Unless the host that
isn't close
         EMail Professional since 1978           Is busy, hung or dead.
                 "He's dead, Jim. I'll get his tricorder. You take his wallet."
                 [apologies to DeForest Kelley, 1920-1999]
         <A Href="http://perdita.lcs.psu.edu">home page</a>
         <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail
declaration</a>
--
       /"\
       \ /     ASCII RIBBON CAMPAIGN
        X        AGAINST HTML MAIL
       / \


* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Mathew Shember]

It's possible in fact I wrote one just to do that.

You have to be careful about the mmrx version level.

I get the versions for mmrx and the mmservernt.    I also have a
versions file  a "blessed" version of mmrx.    Sometimes you can have an
older version of mmrx that will work with a newer version of the server.

The script stops the server, run's mmrx and mails the log files back to us.

I found it easier to convert the perl script to a binary and have the
taskscheduler run it twice a month.   The binary form eliminated the
concern of the perl version and admins that change the perl install.

Automation is a good thing!  :)



Caroline Couture wrote:

> Hi Folks!
>
> We have a new server person on-board and he wants to run the MMRX tool on a
> regular basis via a script.
>
> I'm nervous about running a tool via script that can "repair" a MM database.
>
> What are folks experiences with this, if any? My inclination is to run the tool
> manually as I have always done.
>
> We are running MM 8.5.6 on server 2003 with windows XP clients. We are also
> connected to the central Meeting Maker hub for our University.
>
> What say all?
>
> Thanks!
> Caroline
>  

* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Mathew Shember]

I have never seen it run that long.    Do you have a long data retention?

The newer versions have command line ability that has improved.



J.Lance Wilkinson wrote:

> At 04:07 PM 5/1/2007 -0400, Caroline Couture wrote:
>> Hi Folks!
>>
>> We have a new server person on-board and he wants to run the MMRX
>> tool on a
>> regular basis via a script.
>
>         There was a time when I thought that might be advisable,
> except it took hours
>         to run, with a judgement call between each run, and it's
> clearly intended not to
>         be run from a script but rather as an interactive tool.
>
>         But the last time I ran it was before migrating from v7.5 to
> v8.5 in June of 2005.
>         And indeed it took several hours on our MM databases to clean
> down to zero errors.
>
>         We then migrated to v8.5, with all the hassles of that, and
> never ran MMRX again until
>         March of this year (nearly 2 full years), prior to doing an
> experimental EXPORT so some
>         folks could experiment with the export file being imported
> into Oracle Calendar.
>
>         I was ASTONISHED.   After 2 years on v8.5, the MMRX cleanups
> took less than TWENTY
>         MINUTES to get to zero errors.   That's three databases (two
> servers and a hub) with 400
>         users on one server and 30 on another.
>
>         So maybe the desire to run MMRX regularly is misplaced?  
> They've clearly done a better
>         job in the v8.x days with preventing DB corruptions and live
> recoveries than prior versions
>         had.
>
>         "Never Underestimate the bandwidth of a station wagon full of
> mag tapes"
>         J.Lance Wilkinson ("Lance")                     InterNet:  
> Lance.Wilkinson@...
>         Systems Design Specialist - Lead                AT&T:      
> [phone]
>         Digital Library Technologies                    FAX:      
> [phone]
>         E3 Paterno Library                              "I'd rather be
> dancing..."
>         Penn State University                   A host is a host from
> coast to coast,
>         University Park, PA 16802               And no one will talk
> to a host that's close
>         <postmaster@...>            Unless the host that
> isn't close
>         EMail Professional since 1978           Is busy, hung or dead.
>                 "He's dead, Jim. I'll get his tricorder. You take his
> wallet."
>                 [apologies to DeForest Kelley, 1920-1999]
>         <A Href="http://perdita.lcs.psu.edu">home page</a>
>         <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail
> declaration</a>
> --
>       /"\
>       \ /     ASCII RIBBON CAMPAIGN
>        X        AGAINST HTML MAIL
>       / \
>
>
> * MMXP-TALK Web Page:  
> http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson]

At 01:31 PM 5/1/2007 -0700, you wrote:
>I have never seen it run that long.    Do you have a long data retention?

         At least 6 years.  Yes, it confounded the tech support folks
when we would tell
         them that.   That practice developed long before MMRX was
offered to users and
         long before export/upgrade/import advised 2 years or less as
a best practice.

>The newer versions have command line ability that has improved.


* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Erik Froese-2]

J,
By chance, were you running the mmrx (7.5.3) over an X connection?
We run our server on solaris and it used to take upwards of 6 hours to
run mmrx through our db (~500mb).

MM Techs had always said to avoid Xforwarding, especially over SSH but
I ignored them for a while. I finally gave in and started a X virtual
frame buffer
(essentially a null screen in memory) and it cut the mmrx time down
from 6 hours to just over 5 minutes.

Since the 8.x series tools don't use X at all that may have account
for the drastic speedup in mmrx processing time you saw.

Erik

On 5/1/07, J.Lance Wilkinson <jlw12@...> wrote:

> At 01:31 PM 5/1/2007 -0700, you wrote:
> >I have never seen it run that long.    Do you have a long data retention?
>
>          At least 6 years.  Yes, it confounded the tech support folks
> when we would tell
>          them that.   That practice developed long before MMRX was
> offered to users and
>          long before export/upgrade/import advised 2 years or less as
> a best practice.
>
> >The newer versions have command line ability that has improved.
>
>
> * MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML
>

* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[J.Lance Wilkinson]

At 10:31 AM 5/2/2007 -0400, you wrote:
>J,
>By chance, were you running the mmrx (7.5.3) over an X connection?
>We run our server on solaris and it used to take upwards of 6 hours to
>run mmrx through our db (~500mb).
         No, never.  


* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML

[Ian Eiloart]

--On 1 May 2007 16:22:18 -0400 "J.Lance Wilkinson" <jlw12@...>
wrote:

>
>          I was ASTONISHED.   After 2 years on v8.5, the MMRX cleanups
> took less than TWENTY
>          MINUTES to get to zero errors.   That's three databases (two
> servers and a hub) with 400
>          users on one server and 30 on another.
>
>          So maybe the desire to run MMRX regularly is misplaced?
> They've clearly done a better
>          job in the v8.x days with preventing DB corruptions and live
> recoveries than prior versions
>          had.

I run it daily, with a script. it takes a matter of seconds to cover 10
databases with between 50 and 400 users on each. I never cease to be amazed
that it's necessary to repair a database!

--
Ian Eiloart
IT Services, University of Sussex
x3148


* MMXP-TALK Web Page:  http://WWW.LISTSERV.Emory.Edu/Archives/MMXP-TALK.HTML