locked
UTC-Local time konverzio RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    hali
    sql 2005on kellen local time/UTC kozt konvertalgatni.
    en most azt latom leggyorsabb megoldasnak, hogy felveszek egy tabla 3 oszloppal:
    TimeShift int, -- orakban megadva
    FromDate datetime,
    ToDate datetime

    es feltoltom a megfelelo ertekekkel pl:
    TimeShift FromDate ToDate
    1 2008-10-26 03:00:00.003 2009-03-29 02:00:00.000
    2 2009-03-29 02:00:00.003 2009-10-25 03:00:00.000

    es utana

      

    	select d.*
		, dateadd(hour,-lts1.TimeShift,d.LifespanStart) LifespanStartUTC
		, dateadd(hour,-lts2.TimeShift,d.LifespanEnd) LifespanEndUTC
	from workflowinstanceHistory d
	join LocalTimeShift lts1
		on d.LifespanStart between lts1.FromDate and lts1.ToDate
	join LocalTimeShift lts2
		on d.LifespanEnd between lts2.FromDate and lts2.ToDate

    de ez igy irot nagy IOt csinal, tulkepp 2x FullTableScannal vegignyomja a LocalTimeShift tablat, pedig van rajta index (tobbfelet probaltam, most epp ez van:)

    create

     

    clustered index cl1 on LocalTimeShift (FromDate, ToDate)

    create

     

    index ix1 on LocalTimeShift (FromDate, ToDate) include (TimeShift)

    valakinek van otlete, hogy ezt hogyan lehetne gyorsabban? (a fenti select 5x lassub mint a select * from workflowinstancehistory)


    Potyos
    Monday, June 15, 2009 2:20 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    hát, gondolom az a LocalTimeShift tábla elég kicsi, ezért nem fog indexet használni rá.  Megpróbálhatod ráerőltetni, de szerintem akkor sem lesz gyorsabb, 1 próbát megér, de csak végszükség esetén. (Bár kipróbáltam, nálam éppen használ, igaz sql2k8) Esetleg érdemes lenne a későbbiekben a getutcdate()-t használni,
    Sáfár István
    Tuesday, June 16, 2009 10:26 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Szia
    epp ez a lenyeg, hogy UTC date lesz a tablakban, de a feluletnek pl mar CETet kell visszadnom, ezert a select .. join...
    megneztem, hasznalja az ix1 indexet, nagyon "furan"

    select count(*) from workflowinstancehistory = 509.988 record
    select count(*) from LocalTimeShift = 240 record
    ez esetben a cost:15 573 (igen, 15 ezer)

    delete LocalTimeShift where fromdate >'2011.01.01' (178 rows effected) merthogy nagyon elore mutato datum nem lehet (max 24 orara)
    ez esetben a cost 720 !
    ami azert eleg durva elteres egy ilyen kis tablanal raadasul olyan rekordokat toroltem amikhez eddig sem kellett (volna) nyulnia.
    az exec plan szerint fut egy index seek ezen a LocalTimeShift tablan ez 16%ot visz el, es egy nested looppal ossze joinolja a workflowinstancehistoryval (LifeSpanStart alapjan).
    aztan jon megint egy index seek ezen a LocalTimeShift tablan de mar 65%ot visz el (453 a costja ennek az egy doboznak) amit aztan megint nested looppal kot az eddigi halmazhoz, LifeSpanEnd alapjan.
    nem ertem, hogy ha a ket lekerdezes ugyan azon index alapjan esik neki a LocalTimeShift tablanak (FromDate = xxx) akkor miert van az egyiknek 3x akkor costja mint a masiknak? a LifeSpanStart es LifeSpanEnd elegge keveset szornak (2008.08.14-2009.06.02 ig terjednek, azaz 3 rekordot erintek a LocalTimeShift tablabol (6 fele kombinacioban)

    Potyos
    Tuesday, June 16, 2009 1:16 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Lehet, hogy ez gyorsabb lenne?

    select d.*
		, dateadd(hour,-lts1.TimeShift,d.LifespanStart) LifespanStartUTC
		, dateadd(hour,-lts2.TimeShift,d.LifespanEnd) LifespanEndUTC
	from workflowinstanceHistory d
	join (select 1 as timeshift,           FromDate='2008-10-26 03:00:00.003', ToDate='2009-03-29 02:00:00.000'
			union all
			select timeshift=2,          FromDate= '2009-03-29 02:00:00.003',ToDate='2009-10-25 03:00:00.000') as lts1
		on d.LifespanStart between lts1.FromDate and lts1.ToDate
	join (select 1 as timeshift,           FromDate='2008-10-26 03:00:00.003', ToDate='2009-03-29 02:00:00.000'
			union all
			select 2,           '2009-03-29 02:00:00.003','2009-10-25 03:00:00.000') as lts2
		on d.LifespanEnd between lts2.FromDate and lts2.ToDate
    István Sáfár
    Monday, June 22, 2009 8:48 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    valoszinuleg,
    ha a LocalTimeShift tablaban csak par sort hagyok biztos gyorsabb lesz, mint ezt lattuk is a jovobeni adatok torlese sokat segitett, de a multbeliek azert eleg regre (max 15 evre) is visszanyulhatnak tehat azok a sorok kelleni fognak es 30 union all szeritnem mar lassubb lesz, raadasul jovore at kel irni a selectet hogy ujabb sor keruljon bele :)

    meg mindig nem ertem, hogy ha 2x kell ugyan azt megcsinalnia az SQlnek (egy tablaban megkeresni ugyan azokat a rekrodokat) akkor miet van a ket kereses kozt 3x os COST elteres? :(
    Potyos
    Tuesday, June 23, 2009 7:21 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Igen, 30-nál lassabb lesz. Ha jól sejtem azért nagyobb a cost,
    mert az első join-nál table scan-t, vagy index scan-t fog használni, a másodiknál pedig index seek-et. de ott a Nx fog index seek-et végrahajtani (N= a előző join utáni sorok), ami azt jelenti, hogy sokkal költségesebb lesz mint amikor 1x végig ment a táblán.
    István Sáfár
    Wednesday, June 24, 2009 8:02 AM
    Moderator