Merhaba, günlük serisinin gecikmeli 7. yazısında stajımızın 2. haftasının kalan 2 gününden bahsedeceğim. Baya yoğun bir hafta geçirmekte olduğum ve performans konusu üzerinde çok uğraştığım için biraz gecikmeli oldu bu.
Perşembe günü (12.07.2007) TUrkcell Akademi - İstiklal Cad. binasında staj oryantasyonu vardı. Farklı departmanlardan bir çok stajyer katıldı bu programa. Tüm gün bounca çeşitli sunumlar yapıldı. Sunumlar çok fazla konumuzla alakalı olmadığı için bunları es geçiyorum :)
Cuma günü Ertürk'ün muhteşem "Concurrency and Consistency" sunumu vardı. Güzel bir sunumdu gerçekten. Oracle'ı Oracle yapan mekanizması anlatıldı. Ertürk'ün sunumunu buradan indirebilirsiniz.
Sunum biraz teoride kaldı, pek pratik şansı olmadı maalesef. Fakat en kısa zamanda telafi olarak workshop da yapılacak bu konuda. Vakit bulursam workshop'tan önce veya sonra blog'da bir makale de hazırlayabilirm bu konuda.
Her makaleden önce tek sunudan ziyade bir çok diğer kaynağı da gözden geçiriyorum, bu yüzden zaman alıyor. O yüzden bu makalenin yayınlanması bir hafta gecikti, kusura bakmazsınız heralde :)
Burada elime geçirebildiğim başka sunumları ve ek kaynakları da yayınlamaya çalışıyorum. Geçen senenin staj döneminde, Hüsnü'ün yapmış olduğu "Locks, concurrency and consistency" konulu sunum da ek kaynak olarak gözden geçirmeye değer. Hüsnü'nün sunumlarını da buradan indirebilirsiniz.
Ben bu konudaki bazı notlarını aktaracağım. Sunumları da inceleyerek mutlaka takip edin.
• Lock yapısı database'leri diğer database'lerden ve database'leri normal dosya sisteminden ayırt eden yapıdır. Transaction ve lock yapısı bir database'i database yapan yapıdır aslında. Bİr çok şekilde implement edilebileceği için farklı databse'ler arasında en çok farklılk gösteren yapılardır bunlar.
• Oracle'ın lock yapısı çok başarılı gerçekten. Oracle'ı Oracle yapan da bu. Row bazında kilitlemesi, Lock escalation olmaması, Dirty read olmaması, ne olursa olsun sistemin hep consistent state'de kalması, okuyucuların yazıcıları ve yazıcıların okuyucuları beklememesi... bunlar hep Oracle'ın mükemmel özellikleri. Çoğu diğer database'lerde olmayan özellikler bunlar.
• Oracle, kayıtları row bazında kilitler. Yani bir row (satır) üzerinde değişiklik yapılırken Oracle sadece o satırı kilitler. Bu, tablonun diğer row'larını etkilemez. Bu kilit yazma kilididir, okuyucular aynı row'ı bile okuyabilirler, kesinlikle yazıcıları beklemezler. Diğer database'lerin tablo bazında, page bazında vs. tarzı değişik implementasyonları var. Bazıları da önce row bazında kilitlemesine rağmen, çok fazla referans geldiğinde kilidi page bazına çıkarma, daha sonra tablo bazına çıkarma vs. gibi şeyler yapıyorlar. Buna lock escalation diyoruz. Oracle'da lock escalation yok.
• Lost update denen bir durum var. Şöyle ki: User1 bir row'u okudu, sonra User2 okudu. User1 ona göre işlemini yaptı, commit de etti, fakat user2 bunun farkında değil, o da işlemini yapıp commit etti. Bir örnekle anlatalım: Online satış sistemimiz olsun. Brinci müşteri geldi, ürüne tıkladı, ürünü inceliyor. Üründen stokta bir tane var ve müşteri de stokta var diye görüyor. Sonra ikinci kullanıcı da aynı ürüne bastı ve aynı ürünü inceliyor, o da stokta var görüyor. SOnra birinci kullanıcı "satın al"a bastı ve stoktaki tek ürünü satın aldı, stok miktarında düşüldü. Sonra ikinci kullanıcı da satın almaya karar verdi ve "satın al"a bastı. Stok miktarı -1'e inemeyeceğine ve olmayan ürünü müşteriye satamayacağımıza göre İşte bu durumun kontrol altına alınması gerekiyor. Lost update durumunu kontrol etmek için iki tarz locking mekanizması var:
1- Pessimistic Locking: Birinci kullanıcı row'a eriştiği an kilit konur ve ikinci kullanıcının ulaşması engellenir. Bu, concurrency'i çok düşürür. Ayrıca http stateless bir bağlantı olduğu için bunun implement edilmesi mümkün değil. Oracle'da "SELECT FOR UPDATE" komutu ile bu şekilde select edildiği an kilit oluşturulabilir.
2- Optimistic Locking: Select edildiğinde kayıt kilitlenmez, fakat update edilmeye çalışırken bir şekilde durum tekrar kontrol edilerek durum handle edilir. Oracle'ın default kilitleme mekanizması zaten optimistic, yani normalde zaten okuyucular hiçbir zaman kayıtları kilitlemez. Tek istisnası, pessimistic locking kullanan "SELECT FOR UPDATE" komutu.
Google'a "Pessimistic Locking" yazınca ilk çıkan sayfada zaten güzel bir şekilde anlatılmış bu, kafanıza takıldıysa biraz da burdan okuyabilirsiniz: http://www.agiledata.org/essays/concurrencyControl.html
Optimistic Locking'in çeşitli implementasyonları var.
a) Version Column: Kayıda ayrı bir versiyon kolonu eklenir, buna örneği en son update zamanı koyulur. Böylece yukarıdaki örnekte ikinci müşteri ürünü almaya çalışırken bu kolon kontrol edilerek data'nın değiştiği anlaşılır.
b) Hashing: Data okunduğunda hash'lenir. Update edilirken tablodaki datanın tekrar hash'i alınır, hash'ler farklı çıakrsa data değişmiş demektir.
c) ORA_ROWSCN: Bu oracle'ın 10g versiyonunda geldi. Oracle, her row'a özel bir ROWSCN değeri atar, her update'de bu değer otomatik oalrak değiştirilir. Dikkat ederseniz yukarıdaki iki yöntemi sistemi tasarlayan ve kodlayan kendisi yapıyor, ekstra bir kolon ekliyor veya hash alma kodunu yazıyor. Burada bu işi oracle kendisi yapıyor.
• Block ve Deadlock, adı üstünde, kilitli bir row'un ona referans eden yazıcıları bloklaması demek, deadlock da farklı kaynaklar üzerine kilit koyan iki (veya circular olarak daha fazla) job'ın birbirini beklemesi demek. Oracle deadlock durumlarını tesbit ederek hata döndürür, son yapılan komutun etkilerini de geri alır. (Statement level rollback) Zaten Oracle gibi çok iyi concurrent ve consistent bir sistemde çok nadir görülür.
• Transaction lock'ları datablock'lar içinde saklanır. Transaction ilk değiştirilen veri ile başlar, commit veya rollback edildiğinde sonlanır. Transactionların aktif olup olmadıkları kontrol edilir, hatalı transaction'lar kapatılarak kilitleri sisteme geri bırakılır.
• Latch, lock'lardan daha basit, daha hafif bir birimdir. Lock'lar gibiişlev görür. İşlemcilerin "Test and set", "Load and clear", "Compare and swap" gibi atomik operasyonlarıyla implement edilir. Latch'ler üzerinde bekleyen process'ler bir süre spin ederek busy wait yaparlar. Daha sonra uyutularak belli periyotlarda uyandırılırlar. Bundan PMON process'i sorumludur.
• Latch ve Lockların fazla olması consistency'i bozar ve wait'lerin artmasına neden olur. Biz bunu istemeyiz. DBMS'lerin amaçlarından bir tanesi de minimum sayıda latch ve lock kullanmaktır.
• Oracle, internal lock'lar dışında, "select for update..", "lock table..." gibi sorgular ve DBMS_LOCK paketiyle external olarak da kilit koyulmasına olanak tanır. Fakat consistency bozualacağı için bunları dikkatli kullanmak gerekir. Normal şartlarda Oracle concurrency'i korumak için gerekli kilitleri içinde zaten oluşturur.
• Dirty read, commit edilmemiş data'nın okunması demektir. Oracle dirty read'e izin vermez, okuyucular data değiştirilmiş olsa bile undo block'lardan en son consistent data'yı okur.
• Non-Repeatable (fuzzy) read, bir transaction içinde aynı select sorgusunu birden çok kez çağırdığımızda farklı sonuçların dönmesidir. Bu, çok kullanıcılı sistemlerde muhtemeldir, A transaction'u bir select çalıştırdıktan sonra B Transaction'ı o row'ları update'liyerek commit ederse, A Transaction'u tekrar aynı sorugyu çalıştırdığında farklı sonuç alacaktır.
• Phantom read de, non-repeatable read gibi, fakat burada insert söz konusu. Transaction A where sözcüğüyle bir select çalıştırdıktan sonra B Transaction'u o where şartını sağlayan bir insert yaparsa, A aynı sorguyu tekrar çalıştırdığında farklı sonuç alacaktır.
Bu konudaki notlarım da bu kadar. Bu da önemli ,ayırt edici bir konuydu. Anlamakta güçlük çektiğiniz bir şey varsa Concepts guide'ın ilgili bölümü'nden bir göz atın önce, sonra Kyte'ın kitaplarından pekiştirebilirsiniz.
|
Set as Homepage
Add to Favourites
Recommend
Contact
