Post reply

Help with hitting a wall

  • July 19, 2004 at 2:15 am

    #515043

    excuse my ignorance, but why would hyperthreading affectthe tempDB, growth factor or Transaction log size??

    sureley most of these relate to HD size and space constraints.

    MVDBA

  • July 20, 2004 at 1:56 pm

    #515342

    Hyperthreading won't affect the tempdb, growth factor or tran log size. However it may be the problem for this "Write requests are refused, whereas read requests are processed, and any attempt to scan a new image into the system results in a total stopage and a Network Timeout error, though the machine that's stopped acan still read from the database quite happily".

    I had to turn it off on my quad proc machine as with it my process would hang. Without it the process takes about 3 hours.




    Gary Johnson
    Microsoft Natural Language Group
    DBA, Sr. DB Engineer

    This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed in this post are my own and may not reflect that of my employer.

  • July 20, 2004 at 2:10 pm

    #515350

    One primary key based on the DOcument Identifier which is a GUID.

    A primary key by default is a clustered index. You may want to make this a simple unique constraint. The page tears one of your responders speaks of is because the guids will be sorted by default in asc order and once you hit the fill factor of  the index pages you will begin to tear pages. Since all guids are generated uniquely you are most likely squeezeing the datapage in order every time.


    ============================
    Richard S. Hale
    Senior Database Marketing Developer
    Business Intelligence
    The Scooter Store
    RHale@TheScooterStore.com
    DSK: 830.627.4493

  • January 4, 2005 at 10:22 am

    #535814

    Just in case anyone still cares about this problem, it turned out to be a conflict with the SCSI cards and the scanners (believe it or not). Once a certain volume of data had passed through the SCSI card it just seemed to close itself down until the PC was reset...

    We had the latest SCSI drivers and everything, but that seems to be the cause of the problem. Fortunately the rate at which they are scanning means they switch the PC off at the end of the shift long before the SCSI card packs up.

    I'd just like to thank everyone for the help they gave with this.

     

    Paul Anderson

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply