20 Eylül 2011 Salı

Overview of Concurrency Features / Eşzamanlılık Özelliklere Genel Bakış

All information management systems have these important requirements:
  • 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.
Oracle Database contains several software mechanisms that satisfy these requirements. This contains the following sections:

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
It is the application designer's responsibility to ensure that transactions fully exploit these concurrency and consistency features.
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
In the Oracle Database implementation of read consistency, it is as if each user operates a private copy of the database. This is sometimes called a multiversion consistency model.
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ış )


Tüm bilgi yönetim sistemleri, bu önemli gereksinimleri sahiptir:
  • Bir çoklu kullanıcılı sisteminin veri eşzamanlığı en üst düzeyde olmalıdır.
  • Veri okuma ve tutarlı bir biçimde değiştirilmelidir.İlk kullanıcı veri bitene kadar bir kullanıcı görüntüleme veya değiştirme verileri (diğer kullanıcılar tarafından) değiştirilmemeli.
  • Yüksek performans, veritabanı sistemi birçok kullanıcıdan gelen maksimum verimlilik için gereklidir

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)

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:

  • Okuyucu adına oluşturulan okuma tutarlı görünümleri için başlangıç noktası dikte eder .
  • Değiştirilmiş verileri, okuma ya da güncellemek için veritabanı diğer işlemler tarafından görülebilirliğni denetler
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ığı )

Oracle Veritabanı tarafından sağlanan tutarlılık, okuyun, aşağıdaki hedeflerin sağlar :
  • Bir durum ile görülen veri seti, zaman içinde tek bir noktaya göre tutarlı ve ifade yürütme (bir bildirimde düzeyinde okuma tutarlılığı) sırasında değişmez olduğunu garanti eder.
  • Veritabanı veri okuyucuları, yazarları ya da aynı verinin diğer okuyucuları için beklememezi sağlar.
  • Veritabanı veri yazarları aynı veri okuyucuları için beklememezi sağlar.
  • Eş zamanlı işlemlerde aynı satırları güncellemek için denerseniz, bu yazarlar sadece diğer yazarlar için beklemek sağlar.
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ı)
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 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.

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.
Gönderen zaman: Hiç yorum yok:
Etiketler: , ,

12 Eylül 2011 Pazartesi

Overview of Oracle Real Application Testing / Oracle Gerçek Uygulama Testine Genel Bakış

System changes, such as hardware and software upgrades and patch application, are essential for businesses for compliance and security purposes or to maintain their competitive edge. Oracle Real Application Testing helps you fully assess the effect of system changes on real-world applications in test environments before deploying them in production. Oracle Real Application Testing consists of two features:

Database Replay

Database Replay enables realistic testing of system changes by essentially re-creating the production workload environment on a test system. It does this by capturing a workload on the production system and then replaying it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. This makes possible complete assessment of the impact of the change including undesired results, new contention points, and performance regressions. Extensive analysis and reporting is provided to help identify any potential problems, such as new errors encountered and performance divergences.
With Database Replay, businesses can rapidly test changes and adopt new technologies with a high degree of confidence in the overall success of the effort and at significantly lower risk.
Database Replay can be used to assess the impact of the following types of system changes:
  • Database upgrades, patches, parameter, and schema changes
  • Configuration changes, such as conversion from a single instance to Oracle Real Application Clusters and Automatic Storage Management
  • Storage, network, and interconnect changes
  • Operating system patches, upgrades, and parameter changes and hardware migrations

SQL Performance Analyzer

Changes that affect SQL execution plans can severely impact system performance and availability. As a result, DBAs spend considerable time in identifying and fixing SQL statements that have regressed due to a change.
SQL Performance Analyzer automates the process of assessing the overall effect of a change on the full SQL workload by identifying performance divergence for each statement. A report that shows the net impact on the workload performance due to the change is provided. For regressed SQL statements, appropriate execution plan details, along with recommendations to tune them, is also provided. As a result, DBAs can remedy any negative outcome before their end users are affected and can confirm, with significant time and cost savings, that the system change to the production environment will, in fact, result in net improvement.
You can use the SQL Performance Analyzer to analyze the SQL performance impact of any type of system change. Examples of common system changes include:
  • Database upgrades
  • Configuration changes to the operating system, hardware, or database
  • Database initialization parameter changes
  • Schema changes, such as adding new indexes or materialized views
  • Gathering optimizer statistics
  • SQL tuning actions, such as creating SQL profiles
See Also:
Oracle Database Performance Tuning Guide to learn how to use the SQL Performance Analyzer


Tükçesi:
Sistem değişiklikleri gibi donanım ve yazılım yükseltmeleri ve yama uygulama gibi, uyumluluk ve güvenlik amaçlı işletmeler için gerekli olan veya rekabet güçlerini korumak içindir.Oracle Real Application Testing üretimde dağıtılmadan önce sınama ortamlarında gerçek dünya uygulamaları tamamen sistem değişikliklerinin etkisini değerlendirmeye yardımcı olur.Oracle Real Application Testing iki özellik içerir:

Database Replay

Database Replay bir test sisteminde esas olarak yeniden üretim yükü ortamı tarafından, sistem değişikliklerinin gerçekçi test edilmesini sağlar.Bu üretim sistemi üzerinde bir iş yükü yakalama ve daha sonra kesin zaman, eşzamanlılık ve orijinal iş yükünün işlem karakteristikleri ile bir test sisteminde tekrarlayarak bunu yapar.Bu değişikliğin etkisi istenmeyen sonuçlar, yeni çekişme noktaları ve performans regresyonlar dahil olmak üzere mümkün olan tam bir değerlendirme yapar. Yeni karşılaşılan hataları ve performans farklılıkları gibi herhangi bir potansiyel sorunu tanımlamanıza yardımcı olması için kapsamlı analiz ve raporlama sağlanmaktadır.
Database Replay ile, işletmeler hızla değişiklikleri test edebilirsiniz ve çabaların genel başarısı ve önemli ölçüde daha düşük bir risk içindde yüksek bir güven derecesi ile yeni teknolojileri benimseyebilir.Database Replay sistem değişiklikleri aşağıdaki türleri etkisini değerlendirmek için kullanılabilir:
  • Database yükseltmeleri, yamalar, parametre ve şema değişiklikleri
  • Yapılandırma değişiklikleri, tek bir örneği Oracle Real Application Clusters ve Otomatik Depolama Yönetimi dönüştürme gibi
  • Depolama, ağ ve birbirine değişiklikleri
  • İşletim sistemi yamaları, yükseltmeleri, ve parametre değişiklikleri ve donanım göçler
SQL Performance Analyzer (SQL Performans Analizörü)

SQL yürütme planlarıni etkileyen değişiklikler ciddi şekilde sistem performansını ve kullanılabilirliğini etkileyebilir.Sonuç olarak, DBA'ların bir değişiklik nedeniyle gerilemiş olan SQL ifadeleri belirleme ve tamir etme oldukça fazla zaman alır.
SQL Performans Analyzer tam SQL iş yükünü her ifade için performans sapma tespit ederek herhangi bir değişikliğin genel etkisi değerlendirilmesi süreci otomatik hale getirir.Değişikliği nedeniyle iş yükünü performans üzerindeki net etkisi gösteren bir rapor verilir.Gerilemiş SQL ifadeleri, onları ayarlamak için öneriler ile birlikte uygun yürütme planı ayrıntılarını da sağlanır.Sonuç olarak, DBA'lar üretim ortamına sistem değişikliği, aslında net iyileştirme neden olan son kullanıcılar önemli ölçüde zaman ve maliyet tasarrufu ile etkilenmeden ve onaylanmadan önce, herhangi bir olumsuz sonuç düzeltebilir.
Sistemini değiştirmek her türlü SQL performans etkisi analiz için SQL Performans Çözümleyicisi'ni kullanabilirsiniz. Ortak sistem değişiklikleri örnekler şunlardır:
  • Database yükseltmeleri ,
  • Yapılandırma işletim sistemi değişiklikleri, donanım, veya veritabanı
  • Database başlatma parametre değişiklikleri
  • Şema değişiklikleri, yeni dizinler ya da hayata kez ekleyerek gibi
  • Optimizer istatistikleri toplama
  • SQL SQL profilleri yaratmak gibi ayar eylemler







Gönderen zaman: Hiç yorum yok:
Etiketler: , ,

8 Eylül 2011 Perşembe

Overview of Accessing the Database / Veritabanı Erişimine Genel Bakış

This section describes Oracle Net Services, as well as how to start up the database, in the following sections:

Network Connections

Oracle Net Services is the interface between Oracle Database and the network communication protocols that facilitate distributed processing and distributed databases. Communication protocols define the way that data is transmitted and received on a network. Oracle Net Services supports communications on all major network protocols, including TCP/IP, HTTP, FTP, and WebDAV.
Using Oracle Net Services, application developers do not need to be concerned with supporting network communications in a database application. If a new protocol is used, then the database administrator makes some minor changes, and the application requires no modifications and continues to function.
Oracle Net, a component of Oracle Net Services, establishes and maintains a network session from a client application to an Oracle Database server. Once a network session is established, Oracle Net acts as the data courier for both the client application and the database server, exchanging messages between them. Oracle Net can perform these jobs because it is located on each computer in the network.
See Also:

Starting Up the Database

The three steps to starting an Oracle database and making it available for systemwide use are:
  1. Start an instance.
  2. Mount the database.
  3. Open the database.
A database administrator can perform these steps using Oracle Enterprise Manager, the SQL*Plus STARTUP statement, the srvctl command-line tool, or the Express Edition START command. When Oracle Database starts an instance, it reads the server parameter file (spfile) or initialization parameter file (pfile) to determine the values of initialization parameters. Then, it allocates an SGA and creates background processes.
See Also:
Chapter 12, "Database and Instance Startup and Shutdown"

How Oracle Database Works

The following example describes Oracle Database operations at the most basic level. This illustrates an Oracle Database configuration where the user and associated server process are on separate computers, connected through a network.
  1. An instance has started on the computer running Oracle Database, often called the host or database server.
  2. A computer running an application (a local computer or client workstation) runs an application in a user process. The client application attempts to establish a connection to the server using the proper Oracle Net Services driver.
  3. The server is running the proper Oracle Net Services driver. The server detects the connection request from the application and creates a dedicated server process on behalf of the user process.
  4. The user runs a SQL statement and commits the transaction. For example, the user changes a name in a row of a table.
  5. The server process receives the statement and checks the shared pool (an SGA component) for any shared SQL area that contains a similar SQL statement. If a shared SQL area is found, then the server process checks the user's access privileges to the requested data, and the existing shared SQL area is used to process the statement. If not, then a new shared SQL area is allocated for the statement, so it can be parsed and processed.
  6. The server process retrieves any necessary data values, either from the actual datafile (table) or those stored in the SGA.
  7. The server process modifies data in the system global area. The database writer process (DBWn) writes modified blocks permanently to disk when doing so is efficient. Because the transaction is committed, the log writer process (LGWR) immediately records the transaction in the redo log file.
  8. If the transaction is successful, then the server process sends a message across the network to the application. If it is not successful, then an error message is transmitted.
  9. Throughout this entire procedure, the other background processes run, watching for conditions that require intervention. In addition, the database server manages other users' transactions and prevents contention between transactions that request the same data.
See Also:
Chapter 9, "Process Architecture" for more information background processes

Türkçesi:

Bu bölümde, aşağıdaki bölümlerde veritabanını nasıl başlatılmasının yanı sıra, Oracle Net Services açıklanmaktadır:
  • Ağ Bağlantıları
  • Veritabanı Başlatma
  • Oracle Veritabanı Nasıl Çalışır?

Network Connections (Ağ Bağlantıları)

Oracle Net Services, Oracle Veritabanı ve ağ iletişim protokolleri arasında dağılmış işlem ve dağıtık veritabanları kolaylaştıran arayüzdür.Haberleşme protokolleri veri iletilir ve bir ağ üzerinden alınan yönteminizi tanımlar.Oracle Net Services, TCP / IP, HTTP, FTP ve WebDAV dahil olmak üzere tüm önemli ağ protokolleri üzerindeki iletişimleri destekler.

Oracle Net Services kullanarak, uygulama geliştiricileri, veritabanı uygulamasında ağ iletişimi destekleme ile ilgili olması gerekmez.Yeni bir protokol kullanılırsa, veritabanı yöneticisi bazı küçük değişiklikler yapar ve uygulama hiçbir değişiklik gerektirmez ve işlevini sürdürür.

Oracle Net Services bir bileşeni olan Oracle Net, Oracle Veritabanı sunucusu bir istemci uygulaması bir oturum için bir ağ kurar ve korur.Bir kere ağ oturumu kurulur, Oracle Net, her iki veri istemci uygulama ve veritabanı sunucusu için bunlar arasındaki mesajlar çevirerek veri kuryeri olarak görev yapar.Oracle Net bu işleri gerçekleştirebilir çünkü ağdaki her bir bilgisayarda yer alır.

Starting Up the Database ( Veritabanı Başlatma )

Oracle veritabanı başlayan ve sistemin bütünlüğünü kullanmak için kullanılabilir duruma getirme için üç adım vardır:
  • Bir örneği başlatın.
  • Veritabanına bağlayın.
  • Veritabanını açın.

Bir veritabanı yöneticisi, Oracle Enterprise Manager, SQL * Plus STARTUP deyimi, srvctl bir komut satırı aracı, ya da Express Edition START komutu kullanarak bu adımları gerçekleştirebilirsiniz.Oracle Veritabanı bir örneğinin başladığında, başlatma parametreleri değerlerini belirlemek için sunucu parametre dosyası (spfile) veya başlatma parametre dosyası (pfile'ı) okur.Sonra, bir SGA ayırır ve arka plan işlemleri oluşturur.

How Oracle Database Works

Aşağıdaki örnekte, en temel düzeyde Oracle Veritabanı işlemleri açıklar. Bu, kullanıcı ve ilişkili sunucu işlemi ayrı bilgisayarlarda bir Oracle Veritabanı yapılandırması, bir ağ üzerinden bağlı olduğunu göstermektedir.
  1. Oracle Veritabanı bir örneğini çalıştıran bilgisayarda başladığında, çoğu zaman host ya da veritabanı sunucusu çağrılmaktadır.
  2. Bir uygulama çalıştıran bir bilgisayar (yerel bir bilgisayar ya da istemci iş istasyonu), bir kullanıcı işlemi uygulaması çalışır.Istemci uygulaması doğru Oracle Net Services sürücü kullanarak sunucuya bir bağlantı kurmaya çalışır.
  3. Sunucu uygun Oracle Net Services sürücü çalışıyor.Uygulama sunucusuna bağlantı isteği algılar ve kullanıcı süreci adına adanmış bir sunucu işlemi oluşturur.
  4. Kullanıcı bir SQL deyimi çalışır ve transaction işler. Örneğin, kullanıcı bir tabloda bir satır isimi değiştirir.
  5. Sunucu işlemi bildirimi alır ve benzer bir SQL deyimi içeren herhangi bir paylaşımlı SQL alanı için paylaşılan havuzu (SGA bileşeni) kontrol eder. Paylaşılan bir SQL alanı bulunursa, daha sonra istenen veri sunucu işlemi kullanıcının erişim ayrıcalıklarını kontrol eder ve mevcut paylaşımlı SQL alanı bildirimi işlemek için kullanılır.Değilse, o zaman yeni bir paylaşımlı SQL alanı deyimi için tahsis edilir, bu yüzden çözümlenebilir ve işlenebilir..
  6. Sunucu işlemi gerekli veri değerleri ve gerçek veri dosyası (tablo) veya SGA depolanmış olanlarından yalnızca birini alır.
  7. Sunucu işlemi sistem global alanda veri değiştirir. veritabanı yazıcı süreci (DBWn) diske kalıcı olarak bloklar değiştirilmiş yazıyor ve bunu yaparken verimli olur.
  8. Işlem başarılı olursa, uygulama sunucu işlemi ağ üzerinden bir mesaj gönderir. Başarılı değilse, o zaman bir hata mesajı iletilir.
  9. Tüm bu süreci boyunca, müdahale gerektiren durumlar için diğer arka plan süreçlerini izlerken, çalıştırır. Buna ek olarak, veritabanı sunucusu diğer kullanıcıların işlemlerini yönetir ve aynı veri talep işlemleri arasındaki çekişmesini önler.



Daha fazla Türkçe Kaynak Eklemek İstersek:
*Tonguç bey'in sunumlarından aldığım bazı notları paylaşacağım bu makalede:

• Oracle instance'ı şu dört durumdan birinde olabilir: CLOSED, UNMOUNT, MOUNT, OPEN. CLOSED MODE, instance'ın kapalı olduğu moddur. Bu durumda sadece sysdba olarak bağlanarak instance açılabilir. Instance'ın açılabilmesi için, initialization parameter dosyası veya server parameter dosyası(SPFILE) okunur. Bu dosyalar instance ve database ile ilgili parametereleri içerir. UNMOUNT MODE, instance'ın açılmış, fakat database'in mount edilmemiş durumudur. SPFILE veya initialization parameter file okunur, fakat control dosyaları okunmaz. Control dosyalarımızla ilgili bir problemimiz varsa, instance'ımızı bu mode'da başlatıp problemimizi çözebiliriz. MOUNT MODE, instance açılmış, database mount edilmiş, fakat database açılmamış durumudur. Mount etmek, database'i o instance ile ilişkilendirmek olarak düşünülebilir. Oracle, database'e ait bilgiler (datafileların konumu, redolog dosyalarının konumu vs.) içeren control dosyasını okuyarak database'i mount eder. OPEN MODE, herşeyin açık, database'in ayakta olduğu mode'dur. Redolog dosyaları ve datafile'lar okunur. Database, bir önceki zamanda anormal bir şekilde sonlanmışsa instance recovery yapılır, undo tablespace edinilir.

Database'in her durumunu örneklemek için aşağıdaki kod parçasını çalıştırdım: 
C:\oraclexe\app\oracle\admin\XE\udump>sqlplus

SQL*Plus: Release 10.2.0.1.0 - Production on Cum Tem 13 09:17:54 2007

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Enter user-name: sys as sysdba
Enter password:

Connected to:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> quit
Disconnected from Oracle Database 10g Express Edition Release 10.2.0.1.0 - Produ
ction

Açık bir instance'da olduğum için önce kapattım. Şu anda instance'ımız CLOSED mode'unda. Şimdi login olmaya çalışalım: 
C:\oraclexe\app\oracle\admin\XE\udump>sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Cum Tem 13 09:20:14 2007

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

SQL> conn tcell/tcell
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

Gördüğünüz gibi, normal kullanıcılar login olamıyor, çünkü database kapalı. Sadece sys, sysdba olarak login olabilir. 
SQL> conn sys as sysdba
Enter password:
Connected to an idle instance.

Bağlandık ama idle instance yazıyor. Instance kapalı demek. Bu noktada herhangi bir tabloya erişmeye çalışalım. 
SQL> select * from t;
select * from t
*
ERROR at line 1:
ORA-01034: ORACLE not available

Elbette erişemiyoruz. Şimdi NOMOUNT mode'a alalım: 
SQL> startup nomount
ORACLE instance started.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes

Instance açıldı, parametre dosyası okundu ve SGA allocate edildi. Şimdi database'imiz NOMOUNT Mode'da. Bu noktada bir tabloya erişmeye çalışalım: 
SQL> select * from t;
select * from t
              *
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only

Hımm, bak sen! Neymiş o fixed table/view'lar? 
SQL> select object from v$access;

OBJECT
--------------------------------------------------------------------------------

GV$ACCESS
V$ACCESS
X$KGLDP
X$KGLLK
X$KGLOB
X$KSUSE

6 rows selected.

Sadece bu 6 sistem tablosu tanımlı. Şimdi database'imizi mount edelim, ve yine tabloya erişmeye çalışalım: 
SQL> alter database mount;

Database altered.

SQL> select * from t;
select * from t
              *
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only

Yine aynı durumdayız. Database daha açık değil. User'lar da tanımlı değil. Yine sadece sysdba bağlanıp database'ı açabilir. Şimdi database'i açalım: 
SQL> alter database open;

Database altered.

NAME
--------------------------------------------------
bilal

Sonunda okuduk tablomuzu :) Şu anda database tamamiyle ayakta. Şimdi bir kaç deneme daha yapalım, ama önce instance'ı yine kapatalım: 
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup nomount
ORACLE instance started.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01507: database not mounted

Unmount iken direk OPEN mode'a almaya çalıştık yemedi :) Peki bütün bu adımları yapmak zorunda mıyız db'yi açmak için? Tabiki hayır. Şimdi direk startup diyelim bakalım ne olacak: 
SQL> shutdown immediate
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes
Database mounted.
Database opened.
SQL>

Download Code

Gördüğünüz gibi tek tek bütün işlemleri bizim yerimize yaptı. Herhangi bir sorun yok parametre dosyasında veya control dosyasında. DB açıldı.

• Database kapama komutu 3 türlüdür: SHUTDOWN, SHUTDOWN IMMEDIATE ve SHUTDOWN ABORT. SHUTDOWN normal kapamadır. Mevcut transactionların sonlanmasını bekler, bu arada yenilerine izin verilmez. Hepsi sonlanınca kapanır. Bu özellikle çalışan sistemlerde pek kullanılmaz. SHUTDOWN IMMEDIATE, bütün aktif transaction'ları rollback yaparak hemen kapanır. Genelde bu kullanılır. SHUTDOWN ABORT ise bütün işlemleri anında iptal ederek direk kapatır. Elektriği çekmekle aynı şey denebilir :) Anormal bir kapanmadır. Bu şekilde kapatılırsa ilk açılışta instance recovery yapılır.
"Database and Instance Startup and Shutdown" Concepts Guide'dan 12. Chaper'ın konusu. Biraz daha ayrıntısını okumak isterseniz: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/startup.htm

• OLAP: Online Analytic Processing demektir. OLAP sistemler raporlama sistemleridir örneğin. Bu sistemlerde uzun süreli büyük sorgular çalıştırılır. Optimizaysonu bu ihtiyaçlar göz önünde bulundurularak yapılır. Örneğin, su sistemlerde çok fazla blok okuma ve harddisk'te büyük sort işlemleri yapılacağı düşünülerek configüresyon ve hardware olarak ona göre optimize edilebilir

• OLTP: Online Transaction Processing demektir. OLTP sistemler normal transaction bazında sistemlerdir. Bu sistemlerde kısa sürelik çok sorgu çalıştırılır. Bu sistemlerde aynı anda bir çok kullanıcı bağlı olup çok sayıda ufak sorgu çalıştırılacağı düşünülerek ona göre tune edilir.

• Bir SQL sorgusu sırayla şu adımlardan geçer: Parse, Bind, Execute ve Fetch. Sorgu önce parse edilir. Sonra varsa bind değerleri yerleştirilir. Sonra çalıştırılır ve sonuç fetch edilir. Parsing genelde çok maliyetli bir iştir. Sorgu ve etkilenen objeler analiz edilerek execution plan oluşturulur. Bu nedenle, aynı sorgudan yüzlerde kere çalışacaksa, yüzlerce kez bunu yapmamamak adına, Oracle her çalıştırılan sorguya bir hash değeri atar. Çalıştırılmak istenen sorgu ile daha önce çalıştırılan bir sorgunun hash değeri aynı ise, yani aynı sorgu bir kez daha çalıştırılacaksa tekrar parse edilmez. Böylece parse maliyetinden kurtulunur. Hash değeri SQL'in text'ine göre atandığı için, ufak harf farklılıkları, fazladan boşluk, büyük/küçük harf farkı gibi şeylerde sorgu aynı olsa bile farklı hash değerleri üretilir. Buna dikkat etmek gerekir. Bir de, bind variable kullanma konusunun öne burada kendini gösterir. Bu konunun ayrıntısına bind variable'lar ile ilgili sunumdan sonra gireceğiz.

Beni almış olduğum notların bir kısmı bu kadar. Bunun dışında bir çok farklı konulara da giriş yapıldı, fakat onlar ilerleyen sunumlarda ayrıntılarıyla gelecek, o yüzden burada yazmaya gerek görmedim. Bu makalede genelde startup-shutdown üzerinde durmuş olduk.



(Alıntıdır: http://www.bhatipoglu.com/entry/13/turkcell-staj-gunlugu-5--startup-shutdown )
*Oracle’ın Çalışmasına Bir Örnek
Aşağıdaki örnek bir istemcinin ağ üzerinden sunucudaki veritabanına erişip bir sorgulama yapmasının adımlarını içermektedir.
  1. Oracle veritabanı “host” ya da “database server” olarak adlandırılan bilgisayarda çalışıyor vaziyettedir.
  2. Bir kullanıcı istemci bilgisayarda kullanıcı işlemlerini gerçekleştiren bir uygulama programını çalıştırmaktadır. İstemci bilgisayar sunucu bilgisayar ile bağlantısını uygun Net8 sürücüsünü kullanarak gerçekleştirir.
  3. Sunucu bilgisayarda da uygun bir Net8 sürücüsü çalışıyor vaziyettedir.  Sunucu uygulama programından gelen bağlantı isteğini tespit eder ve kullanıcı işlemine karşılık gelen sunucu işlemini oluşturur.
  4. Kullanıcı bir SQL komutu çalıştırır ve yaptığı değişikliği “commit” eder, yani onaylar.Örneğin kullanıcı bir tablo içerisindeki bir  kaydı değiştirir.
  5. Sunucu işlemi komutu alır ve paylaşım havuzunda bu SQL komutuna benzeyen bir paylaşımlı SQL alanı olup olmadığına bakar. Eğer böyle bir alan bulunursa sunucu işlemi kullanıcının bu SQL cümlesini çalıştırma haklarını kontrol eder. Eğer böyle bir alan yoksa  yeni bir paylaşımlı SQL alanı oluşturulur ve SQL komutu çalıştırılır.
  6. Sunucu işlemi bu SQL komutu için gerekli verilerin SGA’da olup olmadığına bakar. Eğer burada yoksa ilgili veri dosyasından verileri alıp SGA’ya getirir.
  7. Sunucu işlemleri komutun gereklerine göre SGA’daki verileri değiştirir. DBWn değiştirilmiş veri bloklarını gerekli olduğu zaman kalıcı olarak diske kaydeder. SQL komutu onaylandığı için LGWR işlemi yapılan SQL işlemini redo log dosyalarına kaydeder.
  8. Eğer SQL komutunun çalıştırılması başarılı olduysa sunucu işlemi ağ üzerinden istemcideki uygulamaya mesaj gönderir. Eğer başarılı olmadıysa uygun hata mesajını gönderir.
  9. Tüm bu işlemler yapılırken veritabanı sunucusu diğer kullanıcıların aynı ya da farklı veriler üzerindeki işlemlerini de yürütür. Bu işlemlerin yapılabilmesi  ve performansın artırılması için örneğimiz içerisinde anlatılmayan başka arka plan işlemleride gerçekleştirilir.







Gönderen zaman: Hiç yorum yok:
Etiketler: , ,
Kaydol: Kayıtlar (Atom)