none
TTS giver MEGET langsom C5

    Spørgsmål

  • Hej

    Jeg er ved at opgradere en SQL database fra 2010HF01 til 2012SP2HF8.

    En af opdateringerne kører Dutytrans igennem.  Denne del tager på mit setup ca. 4 timer+

    Hvis jeg finder TTSBEGIN/TTSCOMMIT og udmarkerer dem. Tager det 5 minutter.?
    Der er 22.800 Dutytrans der skal opdateres.

    Jeg vil da helst fortsætte med TTS. Mer der ellers nogen steder jeg kan kilde for at få C5 til at køre dette hurtigere.?

    Hardware:

    Alt kører på min egen PC Windows 8.1 CPU: I7-4500U 8GB ram SSD disk.

    Båder SQL server og C5.

    JEG ER ISÆR BEKYMRET FOR DRIFT SITUATIONEN SENERE.

    Mvh Palle


    Palle Schødt Scanditek

    10. marts 2016 14:33

Alle besvarelser

  • Hej Palle

    Det lyder mærkeligt - 22.800 poster er jo næsten ingenting. Hvad får du når du kører C5 Performance Test?

    Hvordan ser din C5.ini ud?

    Hjælper det at sætte C5 i single user mode? (med -S parameteren)

    Har du husket at starte med at køre -ZJSqlsrvr_C5.xal ved førte opstart i C5 2012?

    Er der nogen tilpasninger på felter eller triggere på tabellen DutyTrans?

    Hvad står Recovery til på SQL-serveren? Prøv evt. at sætte den til Simple for at se om det gør en forskel.

    Står SQL-server til at booste sin prioritet?

    Hvilken SQL-version og udgave er der tale om?


    MVH gsl@systemconnect.dk Se også: http://blog.systemconnect.dk/

    10. marts 2016 16:09
  • Hej Gert

    Tak for dine svar.

    Performancetest:
    Maskinhastighed 0.01 Indeks 0
    Beregninger  0.01 Indeks 0

    Database indsæt: 0.94 Indeks 3

    Database Søgning: 0.02 Indeks 0
    Database Slet 0.94 Indeks 3

    C5.ini:

    ; Comments Here
    [C5DbSettings]
    -zsrvr=MIN_Computer

    -DSN=C5SQL
    -zFA,A
    -cDK
    -D.\;.\Country\DK
    -MDAT
    -USupervisor

    Jeg har prøvet både med og uden "-zFA,A" der er ingen forskel.
    -S gør ingen forskel - Jeg er i øvrigt fuldstændig alene på min PC. :-)

    Jeg har IKKE kør med -Zsqlsrvr_C5.XAL Jeg HAR allerede en database fra en Version 2010 på 5000Mb som skal opløftes. :-)

    Dutytrans er fuldstændig uden tilretninger.

    Har prøvet med både full og single mode recovery. Ingen forskel.

    Den stod ikke til at booste prioritet. Det giver heller ikke mærkbar forskel.

    Det er en 2008 R2 Database er i compabilitets level: 2005 (90) Det har heller ikke positiv effekt at hæve Level til 100.

    Det eneste jeg kan se virkelig har effekt er når jeg fjerner TTSBEGIN (og TTSCOMMIT)??

    MVH Palle




    Palle Schødt Scanditek

    10. marts 2016 19:28
  • Hej Palle

    Prøv lige at køre en -Zsqlsrvr_C5.XAL for at se om det gør en forskel. Mest for en ordens skyld.

    I "gamle dage" har du ret i at den kun skal bruges når du laver en ny frisk database.

    Men nu om stunder, så bør den faktisk altid køres ifm. opdatering.

    Så vidt jeg husker bliver 1. index konverteret til et clustered index hvis det ikke allerede er det - men jeg har ikke lige som paratviden om det var mellem 2010 og 2012 det skete (så skal jeg til at grave i gamle noter).

    Men "bundlinjen" er at den skulle være ufarlig at køre på eksisterende data i 2012 (men dog kan tage lidt tid - og fylde din SQL log hvis du ikke kører med recovery=simple).


    MVH gsl@systemconnect.dk Se også: http://blog.systemconnect.dk/

    10. marts 2016 20:04
  • Hej Gert

    Du har ret i det tog tid - og det hjalp heller ikke på hastigheden.

    Det er denne kørsel der tager så lang tid: :-(

        // Uden TTS:    259 Sekunder - 460.000 saleslinearch - 22.800 Dutytrans
        // Med  TTS: 19598 Sekunder - 460.000 saleslinearch - 22.800 Dutytrans

    #MacroLoad(GENERAL)
    #MacroLoad(SQL)

    INT &Linier
    INT &Trans
    INT &Opstart = TimeNow()
    INT &Pos = 0

    TTSBEGIN DutyTrans

    #LOCALMACRO.ConvertLineNoAndNumberOnDutyTrans
        #SQLFieldList(%1,LineNumber,OrigLineNumber,Number,OrigNumberRef,Transaction)
        SEARCH %1 USING NumTransLineIdx WHERE LineNumber <> %1.OrigLineNumber
                                           OR OrigNumberRef <> ''
                                           #ADD(&Linier, 1)
                                           IF &Linier MOD 1000 == 0 THEN
                                               PRINT 'Linier : ', &Linier at 10,10 + &Pos
                                           ENDIF

            SEARCH DutyTrans USING NumTransLineIdx WHERE (SalesBuy == %2 OR SalesBuy == #SalesBuy_SalesPurch)
                                                     AND Number      == %1.Number
                                                     AND Transaction == %1.Transaction
                                                     AND LineNumber  == %1.LineNumber


                #ADD(&Trans,1)
                IF &Trans MOD 100 == 0 THEN
                     PRINT 'Trans : ', &Trans at 10,22 + &pos
                ENDIF

                IF %1.OrigNumberRef THEN
                    SET DutyTrans.Number = %1.OrigNumberRef
                ENDIF
                IF %1.LineNumber <> %1.OrigLineNumber THEN
                    SET DutyTrans.LineNumber = %1.OrigLineNumber
                ENDIF
    //            UPDATE DutyTrans
            END

        END
    #ENDMACRO

        #ConvertLineNoAndNumberOnDutyTrans(SalesLineArch,#SalesBuy_Sales)

    TTSCOMMIT DutyTrans

    print 'tid: ', (TimeNow() - &Opstart)
    Pause

    MVH Palle


    Palle Schødt Scanditek

    11. marts 2016 07:30
  • Hej Palle

    Jeg går ud fra det er dig der har ud-kommenteret UPDATE DutyTrans linjen?

    Ja, selve opdateringskørslen kan du jo bare køre uden TTS'er, men jeg kan godt forstå at du bliver lidt bekymret for driften senere.

    Omvendt så taler vi her om 460.000 søgninger i DutyTrans tabellen. Og det er jo noget helt andet end at løbe 22800 poster igennem :-).

    Og det er ikke helt normalt. Heller ikke når updaten faktisk går ud på at en af de potentielle index-felter opdateres.

    Så jeg tror nu bare jeg ville køre det uden TTS'er (hvis det er et problem det tager så længe) og så se hvad der byder sig når driften går i gang.

    Vi har i hvert fald generelt ikke oplevet at C5 2012 er langsommere end en 2010'er - så jeg ville ikke være nervøs.

    Bemærk: En oplagt optimeringsmulighed (egentligt for Microsoft så det kunne gøres generelt) ville nok være at benytte #USING() syntaxen fremfor USING i begge SEARCH'er.

    Så vidt jeg kan gennemskue er rækkefølgen posterne behandles i nemlig total ligegyldigt her - og på SQL vil det da nok give en forskel at man ikke skal sortere et DutyTrans datasæt 460.000 gange :-).

    Du kan jo evt. prøve (se evt. http://blog.systemconnect.dk/?p=204 for en nærmere beskrivelse)


    MVH gsl@systemconnect.dk Se også: http://blog.systemconnect.dk/

    • Foreslået som svar af Gert Lynge 11. marts 2016 08:12
    11. marts 2016 08:12
  • Hej Gert

    Tak for dine råd.

    Jeg tror jeg tager chancen og kører opdateringen som en er. Jeg har alligevel ikke tænkt mig og sidde og stirre på skærmen til den er færdig. :-/

    Og du har helt ret i at kørslen foretager mange opslag i dutytrans. :-(

    MVH Palle


    Palle Schødt Scanditek

    11. marts 2016 10:14