sorgu zamanla yavaşlıyor.

[Kuri_YJ]

Tekrar Selamlar,

Delphi tarafındaki kodunuzu gördüğümde aklıma gelen bir kaç tavsiyeyi hemen ileteyim.

Her seferinde yeni bir connection oluşturup, her seferindee yeni bir treansaction oluşturup, her seferinde yeni bir SQL oluşturup (Query) oluşturup işlem yapmayın. Eğer Delphi kanadında böyle bir işlem yapacaksanız, sadece SQL komutu işleten IBX componentlerinde IBSQL adında (Hatta üzerinde yıldırım ikonu vardır) onu kullanın. Her seferinde yeni bağlantı oluşturmayın.

Halihazırda bir datamodulde veya benzeri bir yerde bir adet connection'ı sabit tutun. Ona da belli bir transaction nesnesini bağlayın.

Döngüyü kurarken şu şekilde kurun

Kod: Tümünü seç

  .
  .
  IBSQL1.SQL.Text := 'UPDATE TBL_FALAN SET ALAN1 = :P1, ALAN2 = :P2 WHERE ALAN5 = :P3' ;
  IBSQL.Prepare ;

  for intI := 1 to 5000 do 
  begin
    IBSQL1.Close ;
    IBSQL1.ParamByName('P1').AsInteger := intI ;
    IBSQL1.ParamByName('P2').AsString := strKarakterDegisken
    IBSQL1.ParamByName('P3').AsInteger := intKeyAlanim
    IBSQL1.ExecQuery ;
  end ;

  IBSQL1.Transaction.Commit ; // veya CommitRetaining 
  IBSQL1.Unprepare ;
  .
  .

Bu şekilde FB Server'ın sizin hazırladığınız SQL Cümlesini her seferinde yeniden okuyp derlemesine gerek kalmaz. Bu prepare zamanı küçük görülse bile, binlerce kez tekrar ettiğinde yekun tutar.

Kolay Gelsin

[freeman35]

exe eni çalıştıramadım (linux da path farkından)
- Trigger ların için önerim tek trigger yerine 2 trigger kullan yani her sql için bir trigger, bunlara sıra numarısı vererek çalışma sırası belirleyebilirsin.
- Her kayıttan sonra tüm query i çağırmak yerine işlem bittiğinde "tbBatch.Refresh;" kullanmak daha mantıklı.
- Ayrıca ekranı boyama bazen hatırı sayılır vakit kaybına sebep olur. query.DisableControl enablecontrol işe yarayabilir.
Transaction izalasyonunu iyi kurgularsan faydası olacaktır. fib+ da ve dac ta write transaction ı ayrı verebiliyorsun. read için kullanılanlarda ayrı. Kayıt buloğu sonunda CommitRetaining yaparsan server daha performanslı kaydeder.
Kolay gele

[Kuri_YJ]

Selamlar,

Senin kodunu biraz kurcukladım, benim makinemde Saniyede aşağı yukarı 20,000 kayıt kadar atıyordu ( ).

Sanırım biraz tecrübe

Uygulamanın benim elledikten sonraki hali şu adreste, https://www.mediafire.com/?cm38df373gblj6s

Normalde, Commit Retaining yaparsanız zaman içinde yavaşlarsınız ama sizin bahsettiğiniz gibi bir yavaşlama söz konusu olmaz. Ben CommitRetaining kullanarak yaptığım ilk denemede, Saniyede 10,000 Kadar kayıtla başlıyordu, 100,000'i geçince saniyede 1,000 kayda kadar düşüyordu hızı.

Sonra Commit kullandım, sonrasında Transaction'ı active ettim, hiç hız kaybı olmadan 250,000 updatelere paldır küldür geldi ben kestim.

Soracağınız olursa yanıtlarım.

Kolay gelsin.

[kgnonr]

Normalde, Commit Retaining yaparsanız zaman içinde yavaşlarsınız ama sizin bahsettiğiniz gibi bir yavaşlama söz konusu olmaz. Ben CommitRetaining kullanarak yaptığım ilk denemede, Saniyede 10,000 Kadar kayıtla başlıyordu, 100,000'i geçince saniyede 1,000 kayda kadar düşüyordu hızı.
Sonra Commit kullandım, sonrasında Transaction'ı active ettim, hiç hız kaybı olmadan 250,000 updatelere paldır küldür geldi ben kestim.

Gerçektende Commit Retaining yerine Commit kullanmak problemi çözdü. Ayrıca faydalı kodlama önerileriniz için de çok teşekkür ederim. Sayenizde büyük bir yükten kurtuldum .

Şöyle bir sorum olucak ben projelerimde 1 adet database connection ve 1 adet transaction kullandım hep. hal böyle olunca commit kullanmak hali hazırda açık olan olan diğer dataset veya query bağlantılarınıda kapatıyor. Bu durumun önüne geçebilmek için nasıl bir yaklaşım olmalı. FIB+ bileşen setini kullanıyorum. Teşekkür ederim.

[Kuri_YJ]

Selamlar,

Denemedim ama muhtemelen mantık olarak çözecektir. Bu işi yaptığınız yerdeki Transaction'ı ayırın. Yani o iş için yaptığınız transaction nesnesini ayrı koyun ve Query'e bağlayın. Diğer Transaction'lar bundan etkilenmeyecektir.

Kolay Gelsin
Adnan

Not : Sen benim gönderdiğim kodu denedin mi? Senin hızın nasıl oldu, rakamları bir söyler misin.

[kgnonr]

Commit kullanınca kullanınca hiç takılma donma olmadan 5sn de 7000 update yaptı. Fakat Commitupdate giderek yavaşladı. Projemde fib+ kullanıyorum. aynı testleri aynı kodlarla fib+ ile yapınca commit dahil yine yavaşlama ve donma yaptı. bu durum iyice kafamı karıştırdı. siz şu noktaya dikkat ettiniz mi? AFTER UPDATE trigger'ı içerisinde master tablo üzerinde işlem yapan iki adet "UPDATE SET ifadesi var. bunlardan birini silince her durumda hiçbir sorun kalmıyor. ne ibx ne fib+ ne commit ne commit update hangisini kullanırsam kullanayım herşey mükemmel çalışıyor fakat trigger içerisinde iki adet UPDATE SET kullanırsam sorunlar başlıyor. sizce de bu ilginç değilmi. aslında bunu bir video ile anlatmak daha açıklayıcı ve anlaşılır olur. en kısa sürede hazırlayıp paylaşmaya çalışacağım. teşekkür ederim.

[Kuri_YJ]

Triggerında problem vardır.