Üretim ortamı arızalandığında veya sistem özellikle yavaş olduğunda, sorunlu SQL'i awr raporundan alırsınız, ancak optimizasyon uzun süredir optimize edilmiştir ve çözülmemiştir.Şu anda liderlerin veya müşterilerin önünde pek iyi değil. . . Peki, sql ayarlama süresini nasıl kısaltabiliriz ve genel optimizasyon fikri nedir?
SOL ayarlama süresi nasıl kısaltılır, fikriniz nedir? SOL'u optimize etmek istediğimde genel süreç şu şekildedir:
Her şeyden önce, tüm veritabanının işleyişini bilmeliyiz.Veritabanı AWR raporu gibi ayarlama araçlarını zaten tanıttım, bu nedenle burada açıklamayı tekrar etmeyeceğim, çünkü AWR raporu veritabanında sorun olduğunda güçlü bir araçtır. Peki ya veritabanında herhangi bir sorun yoksa? Aslında bu mutlaka doğru değildir.Birçok durumda sistem tamamdır çünkü problemi siz tetiklemediniz.Aslında bir problem var.
Örneğin, bir tablonun dizini geçersizse, belirli bir SOL yalnızca sütuna erişirken tam bir tablo taraması gerçekleştirmelidir; örneğin, belirli bir tablonun özniteliği paralellikle ayarlanır, bu, tabloyu tarayan tüm SOL'lerin paralel olarak yürütüleceği anlamına gelir. Ciddi kaynak çekişmesi, sistemin felç olmasına neden olacaktır.Örneğin, genel geçici tablonuz istatistiksel bilgilerle toplanır ve tabloya erişen SOL'un yanlış bir yürütme planı olabilir. Ancak, AWR raporunuz bu sorunları bulamayabilir.Örneğin, dönem boyunca bu nesnelerle ilişkili SOL hiç yürütülmedi. Hiçbir sorun bulunmaması, sorun olmadığı anlamına gelmez, bu nedenle sorun olabilecek tüm nesneleri elde etmemiz gerekir.Aynı zamanda veri tabanına ait genel bilgileri elde etmek için ilgili tüm dönemler için AWR gibi veri tabanının genel performans raporunu da almamız gerekmektedir. Burada, tek tıklamayla erişim elde etmek için bir komut dosyası kullanmayı düşünebilirsiniz, bu da verimliliği artırabilir.
Daha sonra, genel veritabanı bilgilerini elde ettikten sonra, ayarlama yönü çok nettir ve belirli SOL ayarlanır. Yürütme planı SOL ayarlaması için önemli bir silahtır SOL planını analiz ederek, SOL erişim yolunun verimli olup olmadığına karar verebilir ve onu ayarlayıp optimize edebiliriz. Uygulama planını almanın 6 yolu vardır: Neden? Her biri arasındaki fark nedir? İçeriğin bu bölümü iki gün önce tanıtıldı, böylece kendiniz okuyabilirsiniz.
Daha doğru olması için yürütme planı ve çalışma zamanı istatistiklerini analiz için birleştirmek de gereklidir. Örneğin, kaç mantıksal okuma, kaç fiziksel okuma, sıralama olup olmadığı, özyinelemeli çağrılar olup olmadığı vb.
SOL'un yürütme planı elde edildiğinde, çoğu SOL'ye karşılık gelen tablo ve indeksle ilgilidir. Örneğin, sürücü tablolarının sırasının yanlış olduğundan şüphelendiğimizde, bu tabloların gerçek boyutunu kontrol edeceğiz ve karşılık gelen istatistiksel bilgiler doğru; ayrıca tablonun bir bölüm tablosu olup olmadığı, hangi sütunun bir bölüme sahip olduğu gibi tablonun türünü de önemsiyoruz. , Bölüm türü, vb. Nedir?
Tablo bilgilerine odaklanmanın yanı sıra, dizin bilgilerine de önem veriyoruz. Örneğin, yürütme planında indekslemeye çok uygun olan sorgunun tam bir tablo taramasından geçtiğini görürsek, sütunun indeksi olup olmadığını, bulunursa bu sütunun indeksinin geçersiz olup olmadığını kontrol ederiz. Genel olarak, ister Btree dizini, ister bitmap dizini, isterse işlevsel dizin olsun, dizinin türünü de önemsiyoruz; tek sütunlu bir dizin mi yoksa bileşik bir dizin mi? Bileşik bir dizin ise, hangi sütun önce, dizin bölümleme tablosu üzerine kuruluysa, biz de önemsiyoruz Global bir dizin mi yoksa yerel bir dizin mi vb.
Burada, SOL'de yer alan tüm tablo ve sütunların ilgili bilgilerini doğrudan önümüzde görüntülemek için komut dosyasını kullanabilirsiniz, böylece problem çözme çok verimli olur.
Alan sınırlı. Bugün temel olarak sql optimizasyonu fikrini paylaşacağım ve ilgili komut dosyaları zaman ayırdıktan sonra ayrı ayrı tanıtılacak ~
DBA hakkında daha fazlasını daha sonra paylaşacağım, ilgilenen arkadaşlar buna dikkat edebilir!