Aracılığıyla paylaş

Oracle'dan PostgreSQL için Azure Veritabanı geçişler için en iyi yöntemler

Aşağıdaki senaryolarda Oracle'ın Azure Postgres'e geçişi sırasında karşılaşılan bazı olası zorluklar özetlenmiştir. Önerilen çözümler, kendi geçişlerinizi planlayıp yürütürken karşılaşılan bu zorlukların üstesinden gelmek için yararlı olabilir.

Senaryo: İki ayrı, düşük gecikme süreli, yüksek aktarım hızına sahip istemci uygulaması aynı veritabanı üzerinde bağımsız olarak çalışır durumda bulundu. Her uygulama yanlışlıkla diğerinin önbelleğe alınmış sorgularını arabelleklerden çıkarıyordu. Paylaşılan yük ve birleştirilmiş kaynak çekişmesi, veritabanının paylaşılan arabelleklerinin çok sık boşaltıldığı bir durum oluşturarak her iki sistemde de performansın düşmesine neden oldu.

Önerilen Çözüm: İlk değerlendirmelerinizin, hem sistem genel alanı (SGA) hem de program genel alanı (PGA) bellek yapılarının bellek tüketimi ve kullanım desenleri dahil olmak üzere veritabanı platformu ortamınızın tüm yönlerini yakaladığından emin olun. Kaynak gereksinimlerinizle eşleşen uygun işlem ailesini seçin ve Postgres planlı kapasitenizin gerektiği gibi ayarlandığından emin olun.

İpucu

pg_buffercache uzantısı, kullanımı incelemek için bir araç sağlar ve paylaşılan arabellek önbelleğinde neler olduğunu gerçek zamanlı olarak gözlemlemenizi sağlar.

Arabellek Önbelleği İsabet Oranı

İsabet oranlarını incelemek, önbellek verimliliğini değerlendirmenize ve paylaşılan arabellek boyutunun uygun olup olmadığını belirlemenize olanak tanır. İyi bir önbellek isabet oranı, veri isteklerinin çoğunun disk yerine bellekten sunulduğuna ve en iyi performansı sağladığına işarettir:

SELECT COUNT(*) AS total
, SUM(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty -- # of buffers out of sync with disk
, SUM(CASE WHEN isdirty THEN 0 ELSE 1 END) AS clean -- # of buffers in sync with data on disk
FROM pg_buffercache;

En Sık Erişilen Tablolar ve Dizinler

Hangi tablo ve dizinlere en sık erişildiğini ve/veya arabellek önbelleğinde en fazla alanı kaplayanları incelemek, bellekte önbelleğe alınan etkin noktaları belirlemeye yardımcı olabilir:

SELECT b.relfilenode, relname, relblocknumber
, relkind
--r = ordinary table, i = index, S = sequence, t = TOAST table
--, v = view, m = materialized view, c = composite type
--, f = foreign table, p = partitioned table, I = partitioned index
, COUNT(*) AS buffers
FROM pg_buffercache b
JOIN pg_class c ON c.oid = b.relfilenode
GROUP BY b.relfilenode, relname, relblocknumber, relkind
ORDER BY buffers DESC
LIMIT 10;

Arabellek Önbelleği Çekişmesi

Arabellek önbelleğinizdeki önemli çekişme, birden çok sorgunun aynı arabellek alanı için mücadele ettiğini ve bu da performans sorunlarına neden olabileceğini gösterir. Arabellek erişiminin konumunu ve sıklığını incelemek bu tür sorunların tanılanmasında yardımcı olabilir:

SELECT c.relname, b.relblocknumber, COUNT(*) AS access_count
FROM pg_buffercache b
JOIN pg_class c ON c.relfilenode = b.relfilenode
GROUP BY c.relname, b.relblocknumber
ORDER BY access_count DESC
LIMIT 10;

Senaryo: Postgres platformu yayın döngüleri arasında ve yayınlarını kapsayan bir geçiş çalışması başlatıldı. En son sürümde sunulan yeni özelliklere ve iyileştirmelere rağmen, geçişin başlangıcında seçilen sürüm değişmeden kalmıştır. En iyi performansı ve yeni özellikleri elde etmek için ilk geçiş sonrasında Postgres veritabanı sürümünü yükseltmek için daha sonra eklenen çaba, zaman ve harcamalar yapıldı.

Önerilen Çözüm: Mümkün olduğunda geçiş yaparken Postgres'in en son sürümünün benimsenmesinin önceliğini belirleyin. Postgres topluluk geliştirme ekipleri, her yeni sürümde her bir performans ve kararlılığı sıkıştırmak için inanılmaz derecede sıkı çalışır ve geri almak, performansı kenarda bırakmaya dönüşür. Ayrıca, yeni Azure özelliklerinden tam olarak yararlanın. Yeni Azure Postgres özellikleri şunlardır: SSDv2 depolama alanı, en son altyapı sunucu ailesi ve otomatik dizin ayarlama ve otonom sunucu parametresi ayarlama özellikleri.

Senaryo: Postgres'e ilk kez geçiş yapılan kuruluşlar, yavaş çalışan sorguları tanımlarken en iyi yöntemlere ve yaklaşımlara aşina olmayabilir. Uygun şekilde yeni dizin türleri uygulanırken özel özen ve dikkat gösterilmelidir. Özellikle, Postgres veritabanı altyapısı sorgu ipuçlarını belirtmeye gerek kalmadan sorgu performansını iyileştirmek için tasarlanmıştır.

Önerilen Çözüm: Uzantılar, Postgres'i bu kadar güçlü yapan şeyin ayrılmaz bir parçasıdır. Veritabanınızın en yüksek performansta çalıştığından emin olmanıza olanak tanıyan önemli özellikler sağlayabilecek çeşitli uzantılar vardır. Dikkate alınması gereken bazı önemli uzantılar şunlardır:

  • auto_explain: Belirli bir eşiği aşan sorgular için yürütme planlarını otomatik olarak günlüğe kaydeder. Veritabanı yöneticilerinin her sorguda EXPLAIN'ı el ile çalıştırmadan performans sorunlarını tanılamasına ve sorgu performansını iyileştirmesine olanak tanır.

  • pg_trgm: Trigram eşleştirme yoluyla metin tabanlı verilerin benzerliğini belirlemek için işlevler ve işleçler sağlar. Bu uzantı metin araması, benzer eşleştirme ve benzerlik tabanlı sorgular içeren görevler için kullanışlıdır. Metin sütunlarında GIN veya GIST dizinleriyle birlikte, LIKE sorgularında ve benzerlik aramalarında gelişmiş performans sunar.

  • pg_cron: Düzenli görevlerin doğrudan veritabanı içinde zamanlanması ve yönetilmesini sağlar. Rutin bakım görevlerinin, veri işlemenin ve benzer yinelenen işlemlerin otomasyonunu sağlayarak cron benzeri iş zamanlamasını Postgres ile tümleştirir.

İpucu

Veritabanı işlemleriniz veritabanı nesnelerinin önemli miktarda yinelenen oluşturulmasını ve silinmesini içeriyorsa, eski pg_catalog sistem tablosu demetlerinin sayısı artarak tablo "şişmesi"ne yol açar. pg_catalog birçok veritabanı işlemine dahil olan bir sistem tablosu olduğundan, bu tablodaki aralıksız bakım veritabanı genelinde performansın düşmesine neden olabilir. Yinelenen bir pg_cron zamanlaması yapılandırılarak pg_catalog yeterince korunup uygun şekilde vakumlandığından emin olunabilir.

  • pg_hint_plan: Postgres, el ile müdahaleye gerek kalmadan tutarlı ve güvenilir performans sağlamayı hedefleyerek sorgu ipuçlarının dahil edilmemesi için kasıtlı tasarım kararını verir. Sorgu planı tasarımları üzerinde belirli ve hassas denetime ihtiyaç duyulan bazı senaryolarda pg_hint_plan, SQL açıklamalarına eklenmiş ipuçlarını kullanarak sorgu planlayıcısının kararlarını etkilemek için bir yol sağlar. Bu ipuçları, veritabanı yöneticilerinin karmaşık sorguları iyileştirmek veya planlayıcının kendi başına işleyemeyebileceği performans sorunlarını gidermek için sorgu planlayıcısına belirli planları seçmesi için yol göstermesine olanak sağlar.

Not

Bu örnekler, Postgres veritabanınızda kullanılabilen inanılmaz derecede geniş uzantı kümesinin yüzeyini çizer. Postgres veritabanınızı süper ücretlendirmek için bu uzantıları tamamen keşfetmenizi öneririz. Ayrıca, Postgres'i geçerli özelliklerinin ötesinde genişletme olasılığını gördüğünüz kendi uzantılarınızı yazma olasılığını da göz önünde bulundurabilirsiniz. Güçlü esnek uzantı mimarisi, Postgres'in platform gereksinimlerinizle her zaman uyum sağlayıp gelişebilmesini sağlar.

Senaryo: Bazı durumlarda, eski tablo bölümleme stratejileri binlerce bölümün oluşturulmasına neden oldu. Bu, daha önce kullanıldığında etkili olmuş olsa da, bu stratejiler belirli koşullar altında Postgres'te sorgu performansını yavaşlatabilir. Çok belirli durumlarda, sorgu planlayıcısı sorguyu ayrıştırırken uygun bölüm anahtarını belirleyemeyebilir. Sonuçta elde edilen davranış, genişletilmiş planlama süresi oluşturur ve sorgu planlamasının gerçek sorgu yürütmesinden daha uzun sürmesine neden olur.

Önerilen Çözüm: Aşırı sayıda bölüm oluşturan bölümleme stratejileri gereksinimini yeniden değerlendirin. Postgres veritabanı altyapısı artık aynı veri segmentasyonuna gerek duymayabilir ve bölüm sayısını azaltmak performansı artırabilir. Eski bir bölümleme düzeni değerlendirilirse ve gerekli olduğu belirlenirse, önce dinamik bölüm anahtarlarını tanımlamak ve ayıklamak için sorgunuzu ayrı işlemler halinde yeniden yapılandırmayı ve ardından sorgu işlemlerinizde bölüm anahtarlarını kullanmayı göz önünde bulundurun.

Senaryo: Bazen dış bağımlılıklar ve ortam koşulları hem Oracle hem de Azure Postgres veritabanlarının bir arada var olması gereken karma veritabanı senaryoları gerektirebilir. Örneğin, verileri içeri aktarma veya karmaşık ETL işlemlerini değiştirme yükü olmadan Oracle verilerine doğrudan Azure Postgres'ten erişmek ve bunları sorgulamak için aşamalı geçişlerin gerekli olduğu durumlar olabilir. Diğer durumlarda hem Oracle hem de Azure Postgres ortamlarındaki eşdeğer veri kümelerini aynı anda karşılaştırarak paralel veri doğrulaması gerçekleştirmek, geçiş sırasında ve/veya sonrasında veri tutarlılığı ve bütünlüğü sağlamaya yardımcı olabilir.

Önerilen Çözüm: PostgreSQL Yabancı Veri Sarmalayıcı (FDW) Uzantıları, dış sistemlerde depolanan verilere Azure Postgres veritabanında yerel olarak yer alır gibi erişmenize ve bunları işlemenize olanak sağlayan önemli bir Postgres özelliğidir. FDW'ler, Azure Postgres'in federasyon veritabanı olarak çalışmasını sağlayarak Oracle veritabanları da dahil olmak üzere herhangi bir sayıda dış veri kaynağıyla tümleştirmeye olanak tanır. FDW'ler Postgres veritabanınızda yabancı tablo tanımları oluşturur ve bu yabancı tablolar, kullanıcıların normal SQL sorgularını kullanarak bu yabancı tabloları sorgulamasına olanak sağlayan tanımlı dış veri kaynağınız için ara sunucu görevi görür. Postgres altyapısı, uzak veri kaynağından isteğe bağlı olarak verilerle iletişim kurmak ve verileri koordine etmek için dahili olarak dış FDW tanımını kullanır.

oracle_fdw: (Oracle için Yabancı Veri Sarmalayıcı), Azure Postgres'in içinden Oracle veritabanlarına erişmenizi sağlayan bir Postgres uzantısıdır. Oracle'dan Azure Postgres'e geçiş yaparken oracle_fdw veri erişimi, veri doğrulama, artımlı geçiş ve gerçek zamanlı veri eşitleme sağlayarak önemli bir rol oynayabilir. FDW'leri kullanırken aşağıdaki önemli noktaları göz önünde bulundurmak önemlidir:

  • oracle_fdw aracılığıyla sorguları çalıştırmak, veriler uzak Oracle sunucusundan işlenir ve getirilirken ağ iletişimleri ve kimlik doğrulama anlaşması biçiminde ek yüke neden olur
  • Bazı veri türlerinin sistemler arasında doğru eşlendiğinden emin olmak için özel işleme veya dönüştürme gerekebilir.

oracle_fdw etkili bir şekilde kullanmak, uygulamalarınızın ve verilerinizin genel geçiş işlemi boyunca erişilebilir kalmasını sağlayarak veritabanı geçişini basitleştirmeye ve veri erişilebilirliğini sağlamaya yardımcı olabilir.

İlgili içerik

  • Last updated on