Error 8- USER database read error OLD_VIEW (0xC042)

Starting new thread since my prior question about the max user db size was answered but unfortunately didn't resolve the database issue I'm seeing. Just to recap, have one user with a very large user db (>2Gb) which is constantly being rebuilt by the auto-repair option in GW2014. When I run the standalone GWCheck, I run into one of two problems: either the standalone check errors out because the auto-repair has kicked in or it aborts with the error - "Error 8- USER database read error OLD_VIEW (0xC042)" I have been able to do a structural rebuild of the user db (more than once), but have not been able to successfully run an Analyze/Repair with GWCheck. It will complete (and find no errors) if I don't select the "check contents" option. Is there a magic switch I can use?
regards,
Herbert Chun
  • In article <hchun.7w4t6n@no-mx.forums.microfocus.com>, Hchun wrote:
    > "Error 8- USER database read
    > error OLD_VIEW (0xC042)"

    this starts suggesting a lower level issue

    What file system is this on? It might need some maintenance.

    Is there any anti virus on this system? If so make sure it is NOT
    looking at any of the GroupWise system

    What is the underlaying storage system? Can you check the health and
    status if it.

    Sometimes the biggest thing is simply the thing that is first to trip
    over another problem and then keep tripping over it until sorted out.

    General health checks of the server over all, how much RAM is being
    used, how much disk space is available on root/c: (whichever is the
    operational drive of the unspecified OS) as well as where the mail
    store is.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Hi Herbert,

    In your thread about the DB size you mention that there's another application accessing this mailbox. Is it possible to suspend that application from accessing the mailbox to see if that might be the cause of the issue?

    Cheers,
  • Sorry for not being clear. The app is accessing the Post Office via POP. It calls its own mail account and is not touching this user's mailbox.
    Herbert
  • GW is running on Windows 2008r2 under vmware. The c drive is 80Gb with 33Gb free. The d drive, where the Groupwise system is kept, is 3TB with 677GB free. Groupwise is the only thing running on the server so there is no anti-virus software running. So the file system is NTFS. the vm has 12Gb of RAM and 4 vCPUs. I haven't seen anything running abnormally high in the server stats. It usually shows 5GB of physical memory in use when only GW is running (so about 6GB free). The vmware files are sitting in a SAN and that shows no problems. I haven't run a chkdsk on the virtual data drive in a while (that usually drives up the cpu and memory so I do it during the monthly maintenance window if there's time). I have a maintenance window coming up next weekend, so I can run it at that time. Anything else I should be looking at?
    thanks
    Herbert
  • Hi Herbert,

    Perhaps turn off Auto Database Recovery, see here: https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/data/hgvihp02.html Note you will have to stop/start the POA to put this change into effect.

    Then run a GWCheck, untick Structure, tick Contents and Fix Problems. Let that run, no doubt it will take a while on a mailbox that big. Let us know what errors are found in the resultant log file.

    Don't forget to reenable Auto Database Recovery afterward.

    Cheers,
  • In article <hchun.7w50lb@no-mx.forums.microfocus.com>, Hchun wrote:
    > I have a maintenance window coming up next weekend, so I can run
    > it at that time. Anything else I should be looking at?


    Having an antivirus of some sort that only checks C: might not be a bad
    thing to protect the OS.
    If there are any shares to anywhere on D: perhaps remove them. On a
    Windows box it would be better to share to somewhere on C: where some
    A/V is running, and then can remote in to move things around as needed.

    As per Laura, turning off the Auto Database Recovery while dealing with
    this may help piles because that error does related to conflict on the
    file.


    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!