- Data concurrency of a multiuser system must be maximized.
- Data must be read and modified in a consistent fashion. The data a user is viewing or changing must not changed (by other users) until the first user is finished with the data.
- High performance is required for maximum productivity from the many users of the database system.
Concurrency
A primary feature of a multiuser database management system is concurrency, which is the simultaneous access of the same data by many users. Without adequate concurrency controls, data could be updated or changed improperly, compromising data integrity.One way to manage data concurrency is to make each user wait for a turn. The goal of a database management system is to reduce that wait so it is either nonexistent or not noticeable to users. Data manipulation language operations (inserts, updates, and deletes) should proceed with as little interference as possible, and destructive interactions between concurrent transactions must be prevented. A destructive interaction is one that incorrectly updates data or incorrectly alters underlying data structures. Neither performance nor data integrity can be sacrificed.
Oracle Database resolves these issues by using various types of locks and a multiversion consistency model. These features are based on the concept of a transaction.
The transaction is key to the Oracle Database strategy for providing read consistency. This unit of committed (or uncommitted) SQL statements:
- Dictates the start point for read-consistent views generated on behalf of readers
- Controls when modified data can be seen by other transactions of the database for reading or updating
See Also:
Chapter 4, "Transaction Management"
Read Consistency
Read consistency, as provided by Oracle Database, achieves the following goals:- Guarantees that the set of data seen by a statement is consistent with respect to a single point in time and does not change during statement execution (statement-level read consistency)
- Ensures that readers of database data do not wait for writers or other readers of the same data
- Ensures that writers of database data do not wait for readers of the same data
- Ensures that writers only wait for other writers if they attempt to update identical rows in concurrent transactions
See Also:
Chapter 13, "Data Concurrency and Consistency"
Read Consistency, Undo Records, and Transactions
To manage the multiversion consistency model, Oracle Database uses current information in the System Global Area and information in the undo records to construct a read-consistent view of a table's data for a query. When an update occurs, the original data values are recorded in the database undo records. As long as this update remains part of an uncommitted transaction, any user that later queries the modified data views the original data values. Only when a transaction is committed are the changes of the transaction made permanent. Queries that are initiated after the transaction is committed see the changes made by the committed transaction.Read-Only Transactions
By default, Oracle Database guarantees statement-level read consistency. The set of data returned by a single query is consistent with respect to a single point in time. However, in some situations, you might also require transaction-level read consistency. This is the ability to run multiple queries within a single transaction, all of which are read-consistent with respect to the same point in time, so that queries in this transaction do not see the effects of intervening committed transactions. If you want to run a number of queries against multiple tables and if you are not doing any updating, you can initiate the transaction with commands that define it as a read-only transaction.See Also:
Oracle Database Concepts for more information on transaction-level read consistency
Caching Mechanisms
Oracle Database optimizes database performance by caching in memory user data, log data, dictionary data, and other types of data.Oracle Database also caches query results, so that if a query is repeated, the database can return results from the cache instead of reprocessing the query and reading data from storage. The cached results are stored in a dedicated portion of the shared pool. Query retrieval from the query result cache is faster than rerunning the query. The query result cache enables explicit caching of results in database memory. Frequently executed queries especially see performance improvements when using the query result cache.
Locking Mechanisms
Oracle Database also uses locks to control concurrent access to data. When updating information, the data server holds that information with a lock until the update is submitted or committed. Until that happens, no one else can make changes to the locked information. This ensures the data integrity of the system.Oracle Database provides unique nonescalating row-level locking. Unlike other data servers that escalate locks to cover entire groups of rows or even the entire table, Oracle Database always locks only the row of information being updated. Because the database includes the locking information with the actual rows themselves, it can lock an unlimited number of rows so users can work concurrently without unnecessary delays.
Automatic Locking
Oracle Database locking is performed automatically and requires no user action. Implicit locking occurs for SQL statements as necessary, depending on the action requested.The Oracle Database lock manager maintains several different types of row locks, depending on what type of operation established the lock. The two general types of locks are exclusive locks and share locks. Only one exclusive lock can be placed on a resource (such as a row or a table); however, many share locks can be placed on a single resource. Both exclusive and share locks always permit queries on the locked resource but prohibit other activity on the resource (such as updates and deletes).
Manual Locking
Under some circumstances, you might want to override default locking. With Oracle Database, you can manually override automatic locking features at both the row level (by first querying for the rows that will be updated in a subsequent statement) and the table level.Türkçesi:
Overview of Concurrency Features(Eşzamanlılık Özelliklerine Genel Bakış )
Oracle Veritabanı, bu gereksinimleri karşılayan birçok yazılım mekanizmaları içerir. Bu aşağıdaki bölümleri içermektedir:
- Concurrency (eşzamanlılık )
- Read Consistency (Okunma Tutarlılığı)
- Caching Mechanisms (Ön bellekleme Mekanizmaları )
Concurrency(Eşzamanlılık)
Bir çoklu kullanıcılı veritabanı yönetim sisteminin temel özelliği aynı anda birçok kullanıcı tarafından aynı veri erişim eşzamanlılıktır.Yeterli eşzamanlılık kontrolü olmadan veri, veri bütünlüğünü riske atarak hatalı bir biçimde güncellenmiş veya değiştirilmiş olabilir.
Veri eşzamanlılık yönetmek için bir yol, her kullanıcı için beklemek bir dönüş yapmaktır. Bir veritabanı yönetim sisteminin amacı, ya varolmayan veya kullanıcılar için fark edilmez beklemeleri azaltmak içindir.Veri işleme dili işlemleri (ekleme, güncelleme ve silmeleri) mümkün olduğunca küçük bir girişim olarak devam etmelidir ve eş zamanlı işlemler arasında yıkıcı etkileşimler önlenmelidir.Yıkıcı etkileşim yanlış verileri günceller veya yanlış temel veri yapıları değiştiren birisidir. Ne performans ne de veri bütünlüğü kurban edilebilir.
Oracle Veritabanı, kilitler ve bir multiversion tutarlılık modeli çeşitli tiplerini kullanarak bu sorunları çözer. Bu özellikler, bir transaction kavramı üzerine dayanır.
Transaction okuma tutarlılığı sağlamak için Oracle Veritabanı stratejisi için anahtar konumundadır. Bu işlemiş,(ya da işlenmemiş) birimin SQL deyimleri:
Transaction bu eşzamanlılık ve tutarlılık özelliklerini tam olarak yararlanabilmesi sağlamak için uygulama tasarımcısı sorumluludur.
Read Consistency ( Okunma Tutarlılığı )
Okuma tutarlılığının Oracle Veritabanı uygulamasında,her kullanıcı veritabanının özel bir kopyasını çalışır sanki. Buna bazen bir multiversion tutarlılık modeli denir.
Read Consistency, Undo Records, and Transactions(Okuma Tutarlılığı, Kayıtları Geri Al ve İşlemler )
Multiversion tutarlılık modeli yönetmek için, Oracle Database System Global Area güncel bilgilerini ve bir sorgu için bir tablo verilerini salt tutarlı bir görünüm oluşturmak için geri kayıtlarında bilgileri kullanır.Bir güncelleştirme oluştuğunda, orijinal veri değerleri veritabanının geri alma kayıtlarına kaydedilir.Sürecinde bu güncelleştirme, işlenmemiş bir transaction parçası olarak kalır, daha sonra değiştirilmiş verileri sorgular herhangi bir kullanıcı orijinal veri değerleri görüntüleyebilir.Sadece bir işlem tamamlandığında işlem değişiklikleri kalıcı yapılır. transaction tamamlandıktan sonra başlatılan sorguları taahhüt edilen transaction tarafından yapılan değişiklikleri görülür.
Read-Only Transactions ( Salt Okunur İşlemler )
Varsayılan olarak, Oracle Database deyimi düzeyi tutarlılığı okuma garanti eder.Tek bir sorgu tarafından döndürülen veri kümesi zaman içinde tek bir noktaya göre tutarlıdır.Ancak, bazı durumlarda, Transaction düzeyinde okuma tutarlılığı gerektirebilir.Bu, tek bir işlem içinde birden fazla sorgular çalıştırmak için yeteneklidir, bütün bunlar zaman içinde aynı noktaya bakımından ile okuma-tutarlıdır, böylece bu transaction içindeki sorgular işlemiş transaction müdahale etkileri görmezsiniz.Eğer Birden çok tablo sorguları bir dizi çalıştırmak istiyorsanız ve Eğer herhangi bir güncellenme yapmıyorsanız, salt okunur bir işlem olarak tanımlamak komutları ile transaction başlatabilirsiniz.
Caching Mechanisms( Önbellekleme Mekanizmaları )
Oracle Veritabanı bellek kullanıcı verileri, log verisi, sözlük verisi ve diğer veri tipleri önbelleğe alma veritabanı performansı en uygun hâle getirir.Oracle Veritabanı, sorgu sonuçlarını önbelleğe alır,böylece eğer bir sorgu tekrarlanır ise, veritabanı, yeniden işleme, depolanan sorgu ve okuma verisi yerine önbellek sonuçları geri dönebilirsiniz.Önbelleğe alınan sonuçlar özel bir havuz kısmında saklanır.Sorgu sonucu önbellek Sorgu alma, sorgu yeniden çalıştırarak daha hızlıdır.Sorgu sonucu önbelleğini veritabanı hafızasında sonuçları açık önbellekleme sağlar.Sorgu sonucu önbelleğini kullanırken sık sık çalıştırılan sorguların özellikle performans iyileştirmelerini görülür.
Locking Mechanisms (Kilitleme Mekanizmaları)
Locking Mechanisms (Kilitleme Mekanizmaları)
Oracle Database eş zamanlı veri erişimi kontrol etmek için kilitleri de kullanır. Bilgilerini güncellerken, güncellemesini teslim veya taahhüt edilene kadar, veri sunucusu bu bilgileri bir kilit ile tutar.Bu olana kadar, başka hiç kimse kilitli bilgiyi değişiklik yapamaz.Bu sistemin veri bütünlüğü sağlar.
Oracle Veritabanı benzersiz artmayan satır düzeyinde kilitleme sağlar.Satırlarının tüm grupları ve hatta tablonun tamamını kapsayacak şekilde kilitler artırılır diğer veri sunucuları aksine,
Oracle Database, her zaman bilgiyi güncellenmektedir sadece satır kilitler.Çünkü veri tabanı, gerçek satır kendileri ile kilitleme bilgileri içerir, kullanıcıların gereksiz gecikmeler olmadan eş zamanlı olarak çalışabilmesi için sınırsız sayıda Satırlarının kilitleyebilirsiniz.
Automatic Locking(Otomatik Kilitleme)
Oracle Database, her zaman bilgiyi güncellenmektedir sadece satır kilitler.Çünkü veri tabanı, gerçek satır kendileri ile kilitleme bilgileri içerir, kullanıcıların gereksiz gecikmeler olmadan eş zamanlı olarak çalışabilmesi için sınırsız sayıda Satırlarının kilitleyebilirsiniz.
Automatic Locking(Otomatik Kilitleme)
Oracle Veritabanı kilitleme, otomatik olarak yapılır ve hiçbir kullanıcı eylemi gerektirmez.Örtülü kilitleme istenen eylem bağlı olarak, SQL deyimleri için gerekli olduğu ortaya çıkar.
Oracle Veritabanı kilit yöneticisi, çalışma tipi kilit kurdu bağlı olarak birkaç farklı türde satır kilitlerini tutar.Kilitlerin iki genel tipleri özel kilitler ve paylaşım kilitleridir.Sadece tek bir özel kilit bir kaynak (örneğin, bir satır veya bir tablo olarak) yer olabilir, ancak birçok paylaşım kilitleri tek bir kaynak üzerine yerleştirilebilir.Her ikisi de özel ve paylaşmak kilitlerini her zaman kilitli kaynak sorguları izin verir, ama (bu tür güncellemeler ve siler gibi) kaynak diğer etkinlik engeller.
Manual Locking
Bazı durumlarda, varsayılan kilitleme geçersiz kılmak isteyebilirsiniz.Oracle Veritabanı ile manuel olarak satır düzeyinde (ilk satırlar için bir sonraki açıklamada güncellenecektir sorgulayarak) ve tablo düzeyinde hem de otomatik kilitleme özelliklerini geçersiz kılabilirsiniz.
Daha fazla Türkçe Kaynak Eklemek İstersek:
*
| Turkcell Staj Günlüğü - 7: Concurrency and Consistency |
| Category: SQL-Oracle-PL/SQL Date: 20.07.2007 08:51:05 |
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. 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.• 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. |
Hiç yorum yok:
Yorum Gönder