Kaynak sistemi iyileştirme - gelişmiş
Oracle Satır Kimliği tablosunu bölme
SAP, BIR WHR dosyasındaki WHERE yan tümcesini ROW ID değerine dönüştüren bir betik içeren SAP Note #1043380 yayımladı. Alternatif olarak, SWPM Oracle'dan Oracle R3load'a geçiş için yapılandırıldıysa SAPInst'in en son sürümleri ROW ID bölünmüş WHR dosyalarını otomatik olarak oluşturur. SWPM tarafından oluşturulan STR ve WHR dosyaları işletim sisteminden ve veritabanından bağımsızdır (işletim sistemi/DB geçiş işleminin tüm yönleriyle olduğu gibi).
OSS notu "Hedef veritabanı Oracle olmayan bir veritabanıysa ROWID tablo bölme kullanılamaz" deyimini içerir. Teknik olarak, R3load döküm dosyaları veritabanından ve işletim sisteminden bağımsızdır. Ancak sql Server'da içeri aktarma sırasında paketin yeniden başlatılması mümkün değildir. Bu senaryoda, tablonun tamamının bırakılması ve tablonun tüm paketlerinin yeniden başlatılması gerekir. Her zaman belirli bir bölünmüş tablo için R3load görevlerini sonlandırmanız, tabloyu TRUNCATE uygulamanız ve bir bölünmüş R3load iptal edilirse içeri aktarma işleminin tamamını yeniden başlatmanız önerilir. Bunun nedeni, R3load'ta yerleşik kurtarma işleminin durdurulan R3load işlemi tarafından yüklenen kayıtları kaldırmak için tek satır satır DELETE deyimleri gerçekleştirmeyi içermesidir. Bu yavaştır ve genellikle veritabanında engelleme/kilitleme durumlarına neden olur. Deneyim, bu tablonun içeri aktarılmasını en baştan başlatmanın daha hızlı olduğunu göstermiştir, bu nedenle SAP Note #1043380'da belirtilen sınırlama bir sınırlama değildir.
SATIR KIMLIĞINIn, bölme hesaplamasının kapalı kalma süresinde yapılması gereken dezavantajı vardır; bkz . SAP Notu #1043380.
Kaynak veritabanının birden çok "kopyasını" oluşturma ve paralel olarak dışarı aktarma
Dışarı aktarma performansını artırmanın bir yöntemi, aynı veritabanının birden çok kopyasından dışarı aktarmaktır. Sunucular, ağ ve depolama dahil olmak üzere temel altyapı ölçeklenebilirse, bu yaklaşım doğrusal olarak ölçeklenebilir olma eğilimindedir. Aynı veritabanının iki kopyasından dışarı aktarma işlemi iki kat, dört kopya ise dört kat hızlıdır. Geçiş İzleyicisi, veritabanının her "kopyasından" belirli sayıda tabloyu dışarı aktaracak şekilde yapılandırılmıştır. Aşağıdaki durumda, dışarı aktarma iş yükü dört veritabanı sunucusunun her birine yaklaşık %25 dağıtılır.
- VERITABANı sunucusu 1 & dışarı aktarma sunucusu 1 – en büyük 1-4 tabloya ayrılmıştır (kaynak veritabanında veri dağıtımının ne kadar dengesiz olduğuna bağlı olarak)
- VERITABANı sunucusu 2 & dışarı aktarma sunucusu 2 – tablo bölmeleri olan tablolara ayrılmış
- DB sunucusu 3 & dışarı aktarma sunucusu 3 – tablo bölmeleri olan tablolara ayrılmış
- DB sunucusu 4 & dışarı aktarma sunucusu 4 – kalan tüm tablolar
Veritabanlarının tam olarak eşitlenmiş olduğundan emin olmak için dikkatli olunmalıdır, aksi takdirde veri kaybı veya veri tutarsızlıkları oluşabilir. Sağlanan adımlar tam olarak izlenirse, veri bütünlüğü korunur.
Standart ticari Intel donanım ile basit ve ucuz bir tekniktir, ancak özel UNIX donanımları çalıştıran müşteriler için de mümkündür. Korumalı Alan, Geliştirme, QAS, Eğitim ve DR sistemleri Azure'a taşındığında önemli donanım kaynakları işletim sistemi/VERITABANı geçiş projesinin ortasında serbesttir. "Kopyalama" sunucularının aynı donanım kaynaklarına sahip olması kesin bir gereksinim değildir. Yeterli CPU, RAM, disk ve ağ performansı ile her kopyanın eklenmesi performansı artırır.
Ek dışarı aktarma performansı gerekiyorsa, dışarı aktarma performansını artırmaya yönelik ek adımlar için BC-DB-MSS'de bir SAP olayı açın (yalnızca gelişmiş danışmanlar).
Birden çok paralel dışarı aktarma gerçekleştirme adımları aşağıdaki gibidir:
- Birincil veritabanını yedekleyin ve "n" sunucu sayısına geri yükleyin (burada n = kopya sayısı). Bu örnekte, toplam dört VERITABANı sunucusu yapan n = 3 sunucu olduğunu varsayalım.
- Yedeklemeyi üç sunucuya geri yükleyin.
- Birincil kaynak VERITABANı sunucusundan üç hedef "kopyalama" sunucusuna günlük gönderimi oluşturun.
- Günlük gönderimi birkaç gün boyunca izleyin ve günlük gönderimin güvenilir bir şekilde çalıştığından emin olun.
- Kapalı kalma süresinin başlangıcında PAS dışındaki tüm SAP uygulama sunucularını kapatın. Tüm toplu işlemenin durduruldığından ve tüm RFC trafiğinin durduruldığından emin olun.
- SM02 işlemine "Checkpoint PAS Çalışıyor" metnini girin. Bu, tablo TEMSG'sini güncelleştirir.
- Birincil Uygulama Sunucusu'nu durdurun. SAP artık kapatılıyor. Kaynak db'de başka yazma etkinliği gerçekleşemez. SAP olmayan hiçbir uygulamanın kaynak db'ye bağlı olmadığından emin olun (hiçbir zaman olmamalıdır, ancak VERITABANı düzeyinde SAP olmayan oturumları denetleyin).
- Bu sorguyu Birincil VERITABANı sunucusunda çalıştırın:
SELECT EMTEXT FROM [schema].TEMSG; - Yerel DBMS düzey deyimini çalıştırın:
INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss”(tam söz dizimi kaynak DBMS'ye bağlıdır. EMTEXT içine EKLE) - Otomatik işlem günlüğü yedeklemelerini durdurun. Birincil VERITABANı sunucusunda son bir işlem günlüğü yedeklemesini el ile çalıştırın. Günlük yedeklemesinin kopya sunuculara kopyalandığından emin olun.
- Üç düğümde de son işlem günlüğü yedeklemesini geri yükleyin.
- Veritabanını 3 "kopyalama" düğümünde kurtarın.
- Dört düğümde de aşağıdaki SELECT deyimini çalıştırın:
SELECT EMTEXT FROM [schema].TEMSG; - Dört veritabanı sunucusunun (birincil ve üç kopya) her biri için SELECT deyiminin ekran sonuçlarını yakalayın. Kopya veritabanı ile birincilin aynı olduğunu ve aynı zamanda aynı verileri içerdiğini kanıtlayan her konak adını dikkatle eklediğinizden emin olun.
- Her Intel R3load dışarı aktarma sunucusunda export_monitor.bat dosyasını başlatın.
- Döküm dosyası kopyasını Azure işlemine (AzCopy veya Robocopy) başlatın.
- R3load Azure VM'lerinde import_monitor.bat dosyasını başlatın.
Aşağıdaki diyagramda mevcut bir Üretim VERITABANı sunucusu günlüğünün "kopyalama" veritabanlarına gönderimi gösterilmektedir. Her veritabanı sunucusunun bir veya daha fazla Intel R3load sunucusu vardır.
