[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference futurs::sybase

Title:Sybase on U*IX Platform
Notice:open for business on the FUTURS node
Moderator:SXKITN::DAW
Created:Wed Oct 10 1990
Last Modified:Fri Mar 28 1997
Last Successful Update:Fri Apr 11 1997
Number of topics:507
Total number of notes:1440

504.0. "Sybase restore got write i/o error" by HTSC12::MICKWIDLAM (Water addict, water man) Thu Feb 27 1997 17:12

    Hi,
    
    I'm a novice in Sybase and my customer hit a strange problem related to
    Sybase. Still we cannot fully identify which went wrong.
    
    My customer have two AS 8400 with each got 4 CPU. The 8400s are
    connected via HSZ40-B and running ASE V1.3 over dUnix V3.2D-2. The
    disks that store the databases are on LSM stripped devices. Underneath
    in HSZ level, each stripped device is formed by two mirror sets of
    RZ28M disks. Thus they are on a RAID 0+1 level (with stripeset over
    mirror set).
    
    In normal operation it worked fine, but we got problem with Sybase
    restore action. We worked with a 4.6G database and simulate the problem
    by restoring the database from a TLZ877 tape loader (which connect to
    the CPU, not the HSZ controller). We have more than 50% chance to hit
    the error "dd: write I/O error" and the restore action just hang. Also
    in the HSZ we found that one member of one mirror set was dropped out
    with "device not ready" and the other member of the mirror set cannot
    take up the restore (which supposed it can). This problem is seen only
    in Sybase restore (in almost all of their databases) and not seen in
    normal operation.
    
    Is there anyone have any idea about that? A Sybase consultant (who is
    not familiar with our Unix) said that this may due to certain Sybase
    configuration problem. He pointed out one example that the "max async
    I/O per engine/server" was set to 2**31 (the max of unsigned integer).
    Is this related?
    
    Thanks for any input on this problem.
    
    Mickwid Lam.
T.RTitleUserPersonal
Name
DateLines