Firebird Silinmiş Kayıtlar İstatistikte Görülüyor
Selam Kuri_YJ;
Yok bilmem Code bazında demişssin.
Fazla derine inme bence. Yada in ve çıkma
Hem o kadar derine inebilsek bizlerde birer DB yazardık, Zaten herşeyin yüzeyinden gitmiyoruz mu?
Herkes bir şeyler üretir biz üzerinde iş yaparız.
SELECT çektiğimde boş ama page'lerinde (INDEX PAGE'lerinde) hala dolu. Mantığı nedir?
İlk mesajımda yazdığım aslında herşeyi açıklıyor.
bilirsinki Index ve Recordlar birbiri ile ilişkilidir.
Indexler için de kayıtları da olduğu gibi herhangi bir Sweep yada Alter
kullanmazsan öyle ce bekler. Yani.
Because desem : Her kayıt ta sweep, yada dediğin node lar silinse yeniden oluşturulursa işimiz var yani
ne hız ne mız kalır.
Bilirsinki Bakım yapılırken "DB in use" olmaması gerekir.
Ama illa
Code istiyorsan al : Console.Writeln("Hello FB"); yada Coder Lord da vardır.
Musti' cim sana da selam,
Sanada hak veriyorum. Ama azıcık ingilizce şart be, özellikle
yazılım ile ilgileniyorsan. Ayrıca bazı şeyleri ingilizce okumak yada yazmak konuyu daha net anlatır.
Ben birde onu türkçeye çevirmek için uğraşamazdım. Makale yazsaydım belki haklısın derdim.
Hoşçakalın
Yok bilmem Code bazında demişssin.
Fazla derine inme bence. Yada in ve çıkma

Hem o kadar derine inebilsek bizlerde birer DB yazardık, Zaten herşeyin yüzeyinden gitmiyoruz mu?
Herkes bir şeyler üretir biz üzerinde iş yaparız.
SELECT çektiğimde boş ama page'lerinde (INDEX PAGE'lerinde) hala dolu. Mantığı nedir?
İlk mesajımda yazdığım aslında herşeyi açıklıyor.
bilirsinki Index ve Recordlar birbiri ile ilişkilidir.
Indexler için de kayıtları da olduğu gibi herhangi bir Sweep yada Alter
kullanmazsan öyle ce bekler. Yani.
Because desem : Her kayıt ta sweep, yada dediğin node lar silinse yeniden oluşturulursa işimiz var yani
ne hız ne mız kalır.
Bilirsinki Bakım yapılırken "DB in use" olmaması gerekir.
Ama illa
Code istiyorsan al : Console.Writeln("Hello FB"); yada Coder Lord da vardır.

Musti' cim sana da selam,
Sanada hak veriyorum. Ama azıcık ingilizce şart be, özellikle
yazılım ile ilgileniyorsan. Ayrıca bazı şeyleri ingilizce okumak yada yazmak konuyu daha net anlatır.
Ben birde onu türkçeye çevirmek için uğraşamazdım. Makale yazsaydım belki haklısın derdim.
Hoşçakalın
- Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
Terminatorün bünyesi tamamen biodigital çalışmakla birlikte,
sanal alemde yaşamayı sevmiyor o yüzden, sizin kadar nete bağımlı değil,
forumlara nete çok sık bakmıyor.
Gelelim soruya...
Firebird nasıl çalışır: (Çok kritik bilgiler!!!)
Firebird kesinlikle kayıtları fiziksel update etmez, silmez.
Firebird her zaman insert eder!
delete de kullansanız, update de kullansanız sadece insert yapılır.
Nedir lan bu saçmalık diyenlere, höst! terminatorün eli ağırdır diyorum ve
susup dinlemelerini, öğrenmelerini öneriyorum.
Firebird her durumda yeni bir kayıt yapar ve onu yapan transaction numarasıyla generasyon sırasını takip eder.
Delete mi yaptın 3000 tane?
hah FB gidip abi bunu bunu işaretle şu bu demez!!!!
zaten siz bir yere 1 byte bile yazmak isteseniz sistem gider cluster boyunda okuma yazma yapar unutmayın!!!
FB derki, al şu kaydı yerinde mi bak, hah uygun mu, tamam bunun aynısından bitane kaydet ve numarası da current_transaction, ama bu kayıtları silindi diye insert et.
commit mi ettin?
tamam transaction envanterine o transaction kaydı okeylenir ve artık o kayıtlar silinmiş olarak günceldir. günceli okumak isteyen artık onları göremez çünkü en son generasyon kayıt silinik diye kayıtlıdır.
update için de aynı şey.
haa bu şekilde çöp kayıtlar olmuyor mu eski versiyonlar??
oluyor ama güzelliği de burda,
elinizin altında aynı kaydın bir sürü kopyası yaşıyor.
yani 1000 kişi bile snapshot transaction açsa, hiçbir ekstra işlem yapılmadan hizmet veriliyor.o bin kişinin bini de kendi zaman dilimindeki generasyon kayıtlarla, tam tutarlı yani giriş çıkışları uyumlu bir bilanço çıkartabilir.
En son aktif transaction ile en eski generasyon kayıtlar arasındaki fark belli bir düzeye geldiğinde sweep ve GC devreye girer. bu sayı default 20000 transactiondır.
FB2.0 da GC çalışma tarzı güçlendirilmiş ve daha az maliyetli hale getirilmiştir. Çünkü transaction açıp kapamasını kullanmasını bilmeyen gerzek bir sürü programcı takımı, kodlamayı çok iyi biliyorum diye geçinen takım, ki ben bunları programcıdan bile saymam hiç, çünkü programcılıgın aslı kodlama değil kodlamayı sağlayan felsefedir..
bunlar sistemin içine ediyorlar ve sistem çok fazla record versiyonu oluşuyor, temizlik çok geçiktiği için devreye girdiğinde sistemin imanı gevriyor. düşünün evinizde 1 sene toz almadınız süpürmediniz dağınık yaşadınız. temizlik yapabilmek için sizi evden atarım ben de olsam!
İşte kuri, olay bu.
senin kayıtlar silindi, ama aslında duruyor!
indexler de duruyor..
temizlenince gidecekler.
neden silinmez?
çünkü temizlik başlamadı.
ama korkma silinmiş kaydı güncel transactionlar okuyamaz.
sadece eskiden açılmış, çalışmakta olan snaphot transactionlar ise
okumak zorunda!!!
Oracle garibim tüm bunları yapabilmek için, ki tam yapmıyor, ne taklalar atıyor bir bilseniz..
Başka merak edilen bişey var mı???
sanal alemde yaşamayı sevmiyor o yüzden, sizin kadar nete bağımlı değil,
forumlara nete çok sık bakmıyor.
Gelelim soruya...
Firebird nasıl çalışır: (Çok kritik bilgiler!!!)
Firebird kesinlikle kayıtları fiziksel update etmez, silmez.
Firebird her zaman insert eder!
delete de kullansanız, update de kullansanız sadece insert yapılır.
Nedir lan bu saçmalık diyenlere, höst! terminatorün eli ağırdır diyorum ve
susup dinlemelerini, öğrenmelerini öneriyorum.
Firebird her durumda yeni bir kayıt yapar ve onu yapan transaction numarasıyla generasyon sırasını takip eder.
Delete mi yaptın 3000 tane?
hah FB gidip abi bunu bunu işaretle şu bu demez!!!!
zaten siz bir yere 1 byte bile yazmak isteseniz sistem gider cluster boyunda okuma yazma yapar unutmayın!!!
FB derki, al şu kaydı yerinde mi bak, hah uygun mu, tamam bunun aynısından bitane kaydet ve numarası da current_transaction, ama bu kayıtları silindi diye insert et.
commit mi ettin?
tamam transaction envanterine o transaction kaydı okeylenir ve artık o kayıtlar silinmiş olarak günceldir. günceli okumak isteyen artık onları göremez çünkü en son generasyon kayıt silinik diye kayıtlıdır.
update için de aynı şey.
haa bu şekilde çöp kayıtlar olmuyor mu eski versiyonlar??
oluyor ama güzelliği de burda,
elinizin altında aynı kaydın bir sürü kopyası yaşıyor.
yani 1000 kişi bile snapshot transaction açsa, hiçbir ekstra işlem yapılmadan hizmet veriliyor.o bin kişinin bini de kendi zaman dilimindeki generasyon kayıtlarla, tam tutarlı yani giriş çıkışları uyumlu bir bilanço çıkartabilir.
En son aktif transaction ile en eski generasyon kayıtlar arasındaki fark belli bir düzeye geldiğinde sweep ve GC devreye girer. bu sayı default 20000 transactiondır.
FB2.0 da GC çalışma tarzı güçlendirilmiş ve daha az maliyetli hale getirilmiştir. Çünkü transaction açıp kapamasını kullanmasını bilmeyen gerzek bir sürü programcı takımı, kodlamayı çok iyi biliyorum diye geçinen takım, ki ben bunları programcıdan bile saymam hiç, çünkü programcılıgın aslı kodlama değil kodlamayı sağlayan felsefedir..
bunlar sistemin içine ediyorlar ve sistem çok fazla record versiyonu oluşuyor, temizlik çok geçiktiği için devreye girdiğinde sistemin imanı gevriyor. düşünün evinizde 1 sene toz almadınız süpürmediniz dağınık yaşadınız. temizlik yapabilmek için sizi evden atarım ben de olsam!

İşte kuri, olay bu.
senin kayıtlar silindi, ama aslında duruyor!
indexler de duruyor..
temizlenince gidecekler.
neden silinmez?
çünkü temizlik başlamadı.
ama korkma silinmiş kaydı güncel transactionlar okuyamaz.
sadece eskiden açılmış, çalışmakta olan snaphot transactionlar ise
okumak zorunda!!!
Oracle garibim tüm bunları yapabilmek için, ki tam yapmıyor, ne taklalar atıyor bir bilseniz..
Başka merak edilen bişey var mı???
Terminatör arkadaşım,
Sanki sen ayrı ben ayrı şeylerden bahsetmiş gibi olduk.
Yazdığın şeyler, bahsettiğim konular la aynı değilmi ???
Sadece biraz açmışsın ama, sweep ve garbage collect i mantığını bilen
yazdıklarını az çok bilen kişidir zaten. Kuri_YJ bunuda istemiyordu sanırım.
Daha da derine inmek istiyordu
Dimi Kuri_YJ eğer tatmin olduysan bişi demiyorum
Disconnect!!!
Sanki sen ayrı ben ayrı şeylerden bahsetmiş gibi olduk.
Yazdığın şeyler, bahsettiğim konular la aynı değilmi ???
Sadece biraz açmışsın ama, sweep ve garbage collect i mantığını bilen
yazdıklarını az çok bilen kişidir zaten. Kuri_YJ bunuda istemiyordu sanırım.
Daha da derine inmek istiyordu

Dimi Kuri_YJ eğer tatmin olduysan bişi demiyorum
Disconnect!!!
- Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
musti,
fenerbaçe ya da sarı kanarya aslan, kartal ne okursan oku, ama yeterki
okuduğunu doğru anla. ben futbol saçmalığından nefret eden bir insanım
tuttuğum tek top takımı kendi genital organ takımım.
gelelim sorunun cevabına:
bu işlemi doğrudan yapamazsın. özel kurtarma toolu kullanman lazım.
silinmiş kayıtların bazılarını ya da belli bir zaman dilimi için tabloların eski haline dönmek ACID yapısına aykırıdır.
küçük, ilkel bir örnek vereyim. başka bir tabloyu referens alan bir sürü
tablo vardır bir sistemde, eğer sen bunlardan sadece bazıları için
geçmişe ya da geleceğe gitmeye kalkarsan sistem bütünlüğü tutarlılığı da GİDER! bu işler oyuncak ya da yaz boz tahtası değildir. referansını kaybetmiş bir kaydın kendi de bir anlam taşımaz.
ciddi, profesyonel ve bilimsel projeler üreten insanlar yani metodolojik çalışanlar için bu tip işlemler özel müdahale ve itina gerektirir çok istisna durumlardır. ama bazı db sistemleri müşteri haklıdır, ne istese yeridir prensibiyle bunlara izin verebiliyor.
bu geri getirme işlerine en uygun db FB olmasına rağmen buna izin vermez legal yollardan.
ama uzun süredir FB geliştirenlerle bu konuyu konuşuyorum, point in time fonksiyonu önümüzdeki yıllarda mutlaka eklenecek. yeri gelince lazım olabiliyor işi bilene. bilinçsiz yapılan her iş zaten bir kumardır.
çok lazım oluyorsa, sana birkaç yöntem önerebilirim.
FB de sınırsız ve sorunsuz n sayıda aynı anda replikasyon yapılabilir.
çok lazımsa sürekli sistemi kasmadan replikasyon alan uygulamalar çalıştır tut. mesela her saat bir kopya atsın biyere.
ya da her saat bir snopshot transaction aç ve açık tut!
bişey olursa, hangi saate dönmek istiyorsan açık olan o transactionı kullanarak eski bilgileri istediğin gibi geri getir.
fenerbaçe ya da sarı kanarya aslan, kartal ne okursan oku, ama yeterki
okuduğunu doğru anla. ben futbol saçmalığından nefret eden bir insanım
tuttuğum tek top takımı kendi genital organ takımım.
gelelim sorunun cevabına:
bu işlemi doğrudan yapamazsın. özel kurtarma toolu kullanman lazım.
silinmiş kayıtların bazılarını ya da belli bir zaman dilimi için tabloların eski haline dönmek ACID yapısına aykırıdır.
küçük, ilkel bir örnek vereyim. başka bir tabloyu referens alan bir sürü
tablo vardır bir sistemde, eğer sen bunlardan sadece bazıları için
geçmişe ya da geleceğe gitmeye kalkarsan sistem bütünlüğü tutarlılığı da GİDER! bu işler oyuncak ya da yaz boz tahtası değildir. referansını kaybetmiş bir kaydın kendi de bir anlam taşımaz.
ciddi, profesyonel ve bilimsel projeler üreten insanlar yani metodolojik çalışanlar için bu tip işlemler özel müdahale ve itina gerektirir çok istisna durumlardır. ama bazı db sistemleri müşteri haklıdır, ne istese yeridir prensibiyle bunlara izin verebiliyor.
bu geri getirme işlerine en uygun db FB olmasına rağmen buna izin vermez legal yollardan.
ama uzun süredir FB geliştirenlerle bu konuyu konuşuyorum, point in time fonksiyonu önümüzdeki yıllarda mutlaka eklenecek. yeri gelince lazım olabiliyor işi bilene. bilinçsiz yapılan her iş zaten bir kumardır.
çok lazım oluyorsa, sana birkaç yöntem önerebilirim.
FB de sınırsız ve sorunsuz n sayıda aynı anda replikasyon yapılabilir.
çok lazımsa sürekli sistemi kasmadan replikasyon alan uygulamalar çalıştır tut. mesela her saat bir kopya atsın biyere.
ya da her saat bir snopshot transaction aç ve açık tut!
bişey olursa, hangi saate dönmek istiyorsan açık olan o transactionı kullanarak eski bilgileri istediğin gibi geri getir.
- sadettinpolat
- Moderator
- Mesajlar: 2131
- Kayıt: 07 Ara 2003 02:51
- Konum: Ankara
- İletişim:
- Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
tuttuğum takımlarım hangi ligde:
esas ligde, her maçı tek kale bir derby! ama nedense yenilen takım daha da mutlu ahahahaaa
program yazarken takımımı tutmaya devam ediyor muyum:
1.si ayak parmaklarımı program yazdırmayacak kadar severim.
2.si tövbe ettim 6 senedir program yazmıyorum, alem buysa ben yokum dedim. maksat para kazanmaksa daha akıllıca ve optimistik yolları var,
haa maksat haz almaksa, onun da kendine göre takımları, maçları var...
esas ligde, her maçı tek kale bir derby! ama nedense yenilen takım daha da mutlu ahahahaaa
program yazarken takımımı tutmaya devam ediyor muyum:
1.si ayak parmaklarımı program yazdırmayacak kadar severim.
2.si tövbe ettim 6 senedir program yazmıyorum, alem buysa ben yokum dedim. maksat para kazanmaksa daha akıllıca ve optimistik yolları var,
haa maksat haz almaksa, onun da kendine göre takımları, maçları var...
- Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
- Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!