MAKSİMUM MEVCUDİYET MİMARİSİ. Oracle Exadata Storage Server a Geçmenin En İyi Yöntemleri. Yüksek Mevcudiyet için En İyi Oracle Yöntemleri

Transkript

1 Oracle Maksimum Mevcudiyet (Availability) Mimarisi White Paper Eylül 2008 MAKSİMUM MEVCUDİYET MİMARİSİ Yüksek Mevcudiyet için En İyi Oracle Yöntemleri

2 Yönetici Özeti... 2 Önkoşullar ve Amaçlar...3 Geçiş Öncesi En İyi Yöntemler...3 Kapasite Planlaması Yapın... 3 Exadata Konfigürasyon Otomasyonu Kullanın... 4 Infiniband Ağının Oracle Clusterware ve RAC (Real Application Cluster) İletişimi için Kullanıldığından Emin Olun... 5 Uygun ASM Yazılım ve Disk Grubu Özellikleri Olduğundan Emin Olun... 6 Uygun Veritabanı Yazılımı ve Uyumluluğu Olduğundan Emin Olun... 6 DB_BLOCK_CHECKSUM ı Özelleştirin...6 En İyi Geçiş Yöntemleri...7 ASM Ayırma Ünitesi Büyüklüğünü 4MB a Ayarlayın... 7 Optimal Veritabanı Kapsam Büyüklüklerini Ayarlayın... 7 Doğru Geçiş Stratejisini Seçin...7 Mantıksal Geçişler Veritabanı Kapsam Büyüklüğü Değişimi... 9 Oracle Exadata Storage Server üzerinde Yeni Tablo Alanları Yaratma..10 Mantıksal Standby Veritabanları Kullanarak Geçiş Yapma Oracle Streams ve Data Pump Kullanarak Geçiş Yapma Data Pump Kullanarak Geçiş Yapma Fiziksel Geçişler Veritabanı Kapsam Büyüklüğü Değişimi Olmadan...12 ASM Yedeklemesi Kullanarak Geçiş Yapma...12 Fiziksel Standby Kullanarak Geçiş Yapma...13 RMAN (Recovery Manager) Kullanarak Geçiş Yapma Taşınabilir Veritabanı Kullanarak Geçiş Yapma Taşınabilir Tabloalanları Kullanarak Geçiş Yapma Geçiş Sonrası En İyi Yöntemler...16 Disk Gruplarını Yeniden Dengeleme için Kontrol Edin Dizin Gerekliliklerini Değerlendirin Referanslar... 17

3 YÖNETİCİ ÖZETİ Oracle Exadata Storage Server veritabanı zekâsının depolama seviyesinde yerleştirildiği veritabanı teknolojisinde devrimsel bir gelişmedir ki bu yolla önemli uygulama performans kazançları sağlanır. Oracle Exadata Storage Server ile ilgili teknik bir genel bakış edinmek için standart kullanıcı dokümantasyonuna bakınız. Bu kâğıt mirasî depolamadan (legacy storage) Oracle Exadata Storage Server a geçiş öncesi (premigration), geçiş (migration) ve geçiş sonrası ( post migration) için en iyi yöntemleri tanımlamaktadır. Bu yöntemler uygulama servis seviyesi ve onun özellikleri verildiğinde en uygun geçiş stratejisini belirlemede yardımcı olur.

4 ÖNKOŞULLAR VE AMAÇLAR Bu kâğıt Exadata Storage Server kavramlarını ve geçiş stratejilerini yüksek bir seviyede tartışmaktadır. Bu yüzden Exadata Storage Server ve depolama sistem kavramlarıyla ilgili genel bir bilgi sahibi olduğunuzu var saymaktadır. Belirli Exadata Storage Server kavramları, işlevselliği, dizini ve örnekleri ilgili daha detaylı bilgi standart kullanıcı dokümantasyonundadır. Belirli geçiş kavramları ve stratejileri için Referanslar bölümündeki belgeleri inceleyiniz. GEÇİŞ ÖNCESİ İZLENMESİ GEREKEN EN İYİ YÖNTEMLER Geçişe başlamadan önce aşağıdaki en iyi yöntemleri uygulayınız: Kapasite Planlaması Yapınız Exadata Donanımını Doğrulayınız Exadata Konfigürasyon Otomasyonunu Kullanın Infiniband Ağının Oracle Clusterware ve RAC (Real Application Cluster) İletişimi için Kullanıldığından Emin Olun Uygun ASM Yazılımı ve Disk Grup Özellikleri olduğundan emin olun Uygun Veritabanı ve Uyumluluğun Olduğundan Emin olun DB_BLOCK_CHECKSUM ın Etkinleştirildiğinden Emin Olun Kapasite Planlaması Yapınız Kapasite planlaması yaparken şu basamakları uygulayınız: 1. Mevcut ortamınızın kapasitesini belirleyiniz. Oracle Exadata Storage Server a geçmeden önce I/O kapasitesini ve mevcut ortamınızın özelliklerini anlamanız gerekir. Mevcut depolama sisteminizin kullanılabilir ölçeği 1, IOPS (Saniyelik I/O) ve MBPS (Saniyelik Megabayt akışı)sini toplayın. Kaynak sistemdeki mevcut MBPS yi anlamanıza yardımcı olması için sistem istatistiklerini(fiziksel IO disk baytlar) kullanın. Kaynak Sistemdeki mevcut IOPS yi anlamada yardımcı olması için sistem istatistikleri (fiziksel okumalar ve fiziksel yazılar) ı kullanınız. Bu istatistikler, en iyi AWR (Automatic Workload Repository-Otomatik İş Yükü Deposu) raporunda toplanır veya gözlenir. 2. Oracle Exadata Storage Server hücrelerinin tam sayılarını tanımlayınız. Mevcut sisteminizin kapasitesini anladığınızda Oracle Exadata Storage Server hücrelerinin doğru sayılarının konfigürasyonunu yapabilirsiniz. Performans ve kapasitenin ölçeklenmesi önemlidir. 12 SAS sürücüleriyle konfigürasyonu yapılmış bir HP DL180 G5 Exadata hücresi 1.78 TB (Terabayt) kullanılabilir depo, çok büyük I/O lar için saniyede 1GB (Gigabayt) lık bir verimlilik ve küçük I/O lar için 2700 IOPS sağlar 2. 1 Oracle Exadata Storage Server kullanan tipik ASM disk grupları normal fazlalıklardır. Bu yüzden kullanılabilir kapasite toplam kapasitenin yarısıdır. 2 Bu konfigürasyon gelecek yayınlarda değişebilir.

5 . 3. Arıza sonrası I/O kapasitesinin arızalara karşı tolerans sağlayacak kadar yeterli olduğundan emin olun. Kapasite planlaması yaparken arızaları da göz önünde bulundurmak önemlidir. Oracle Exadata Storage Server hücre ve disk arızalarının ASM (Automatic Storage Management- Otomatik Depolama Yönetimi) yedekliği kullanılarak şeffaf biçimde toleransları sağlanmaktadır. Yine de en iyi yöntem, arıza sonrası I/O kapasitesinin yedekleme gereklilikleri ve performans servis seviyelerini karşılayabilecek kadar yeterli olduğundan emin olmaktır: Yedekleme bakış açısıyla, bir diskte arıza olursa ASM otomatik olarak hücreyi veya disk içeriğini disk grubundaki kalan disklere aktaracaktır. Tabii bunu yapması için kalan disklerde yeterince yer olması gerekmektedir. Performans bakış açısıyla, bir hücre veya disk arızalanırsa kalan diskler, performans servis seviyesi anlaşmasına uygun ilerleyebilmek için gerekli MBPS veya IOPS yi üretebilmelidir. Exadata Sabit Diskini Doğrulayın Exadata sabit diskini doğrulamak için aşağıdaki adımları takip ediniz: 1. Aşağıdaki adımları takip ederek kablo bağlantılarını doğrulayınız: Uygun bağlantıların yapıldığından emin olmak için bütün kablolara bakın. cat /sys/class/net/ib?/carrier komutunu bütün devrelerde (nodes) için çalıştırın ve çıktının 1 olduğundan emin olun. ls -l /sys/class/infiniband/*/ports/*/*errors* komutunu çalıştırın ve hataları kontrol edin. 2 Hücre gerekliliklerini beklenen MBPS ve IOPS leri cellcli de CALIBRATE komutunu çalıştırarak doğrulayın. 3 RDS-seviyesi ağ bağlantısı ve band genişliğini, rdsstres komutunu bütün hücreler ve veritabanı sunucu devreleri (nodes) arasında çalıştırarak doğrulayın. 4 Uygun hücrelerin ve veritabanı sunucularının Infiniband ağ yapısında olduğunu ibnetdiscover komutunu bütün hücre ve veritabanı sunucu devrelerinde çalıştırarak doğrulayın. Exadata Konfigürasyon Otomasyonunu Çalıştırın Aşağıdaki Oracle Exadata Storage Server araçları ve özelliklerinden konfigürasyon görevlerini otomasyona geçirmek ve basitleştirmek için kullanın:, CELLCLI komutları: o CREATE CELLDISK ALL Bu CELLCLI komutu, bütün mevcut mantıksal birim numaraları (logical unit numbers-luns) üzerinde otomatik olarak hücrediskleri (celldisks) yaratır. o CREATE GRIDDISK ALL Bu CELLCLI komutu, bütün mevcut hücrediskleri üzerinde otomatik olarak ızgara diskleri (griddisks) yaratır. ASM otomatik arıza grup tespiti: ASM yedeklemesi kullanan mevcut bir disk grubunda, V$ASM_DISKGROUP görüntüsündeki USABLE_FILE_MB ve REQUIRED_FREE_MIRROR_MB sütunları kullanılabilir alan ve yedekleme alanının miktarını sırasıyla verirler.

6 Oracle Exadata Storage Server üzerinde ASM arıza grupları yaratırken aynı Oracle Exadata Storage Server hücresindeki ızgara diskleri otomatik olarak aynı ASM arıza grubuna yerleştirilir. Disk grubu yaratırken arıza grubunu özelleştirmeye gerek yoktur. Böyle olması CREATE DISKGROUP (DİSK GRUBU YARAT) dizinini oldukça kolaylaştırır. Dcli Oracle Exadata Storage Server her hücresinde Dcli aracını içermektedir. Bu aracı, paralel durumdaki tanımlanmış bir hücre kümesine komut veya betik vermek için kullanabilirsiniz. Dcli aracı bütün hücrelerde ya da onların alt kümelerinde çalışması gereken herhangi bir operasyonu oldukça basitleştirir. Bütün hücrelerde SSH kullanıcı denkliği konfigürasyonunu yapmak Dcli kullanımının optimizasyonu için önemli bir önkoşuldur. Dcli SSH özel anahtarlarının dağılımlarını authorized_keys dosyasına otomasyonunu yapmada -k opsiyonunu sağlar. Infiniband Ağının Oracle Clusterware ve RAC İletişimi için Kullanıldığından Emin Olun Eğer Oracle Clusterware ve Oracle RAC kullanıyorsanız, bütün ağ ve depolama iletişimlerinizde Infiniband Ağı kullanmanız en iyi yöntem olacaktır. Infiniband konfigürasyonu önceden hücrelere üzerine yapılandırılır fakat aşağıdakiler veritabanı sunucusu üzerinde doğrulanmalıdırlar: 1. Oracle Clusterware iletişimi için kullanılan özel ağın Infiniband arayüzü kullandığından emin olun. Şu komutu vererek bu durumu doğrulayabilirsiniz oifcfg getif -type cluster_interconnect 2. Oracle RAC iletişimi için kullanılan özel ağın RDS yi Infiniband ağı üzerinde aşağıdaki mesaj için uyarı günlüklerini kontrol ederek çalıştırdığından emin olun: Cluster iletişimi bu seferlik aşağıdaki arayüz(leri)ü kullanmak için yapılandırıldı: cluster interconnect IPC version: Oracle RDS/IP (soysal-generic) RDS çalışmıyorsa oracle ikilisini (oracle binary) aşağıdaki yolla yeniden birleştirin: o Oracle binary kullanan her türlü işletimi kapatın. o cd $ORACLE_HOME/rdbms/lib o make -f ins_rdbms.mk ipc_rds ioracle

7 Uygun ASM Yazılımları ve Disk Grup Özellikleri Olduğundan Emin Olun ASM yazılımlarının ve uyumlu özellik ayarlarının aşağıdaki şekilde ayarlandıklarını doğrulayın: 1. Oracle ASM yazılımlarının çalışma sürümleri olmalıdır. 2. Oracle Exadata Storage Server ızgara diskleri içeren ASM disk grupları için özellik ayarlarını aşağıdaki gibi özelleştirin: COMPATIBLE.ASM özelliğini e ayarlayın. COMPATIBLE.RDBMS özelliğini e ayarlayın. CELL.SMART_SCAN_CAPABLE özelliğini DOĞRU (TRUE) olarak ayarlayın. Uygun Veritabanı ve Uyumluluğun Olduğundan Emin Olun Oracle Exadata Storage Server ızgara disklerine erişmek için Oracle Veritabanı yazılım sürümünü ve COMPATIBLE parametresini aşağıdaki gibi ayarlayın. 1 Oracle Veritabanı yazılım sürümünün çalışma sürümü olmalıdır. 2 Veritabanı COMPATIBLE başlatma parametrelerini e ayarlayın. DB_BLOCK_CHECKSUM Komutunu Etkinleştirin Oracle Exadata Storage Server HARD 3 (Hardware Assisted Resilient Data) uyumludur. HARD özelliğini tam olarak kullanabilmek için DB_BLOCK_CHECKSUM başlatma parametresini TYPICAL(TİPİK) veya FULL (TAM) olarak ayarlayın. Bunlar veritabanı sağlamalarının toplandığının ve bloklarda depolandıklarının güvencesini verecektir. 3 HARD uyumluluğu ile ilgili daha fazla bilgi için:

8 EN İYİ GEÇİŞ YÖNTEMLERİ Aşağıdaki bölümler mevcut bir veritabanını Oracle Exadata ya geçirmenin en iyi yöntemlerini açıklamaktadır: ASM Ayırma Ünitesi Büyüklüğünü 4MB a ayarlayın Optimal Veritabanı Kapsam Büyüklüklerini ayarlayın Doğru Geçiş Stratejisini Seçin ASM Ayırma Ünitesi Büyüklüğünü 4MB a Ayarlayın Oracle Exadata Storage Server, 4 MB lık bitişik birimlerde (contiguous chunks) tarama yaptığı zaman en iyi çalışır. Bunun ASM seviyesinde olduğundan emin olmak için disk grubunun ayırma ünitesi (allocation unit) büyüklüğü 4MB a ayarlanmalıdır. Bu parametre disk grup yaratımı sırasında ayarlanır ve daha sonra değiştirilemez. Mevcut disk grubunun ayırma birimi büyüklüğünü belirlemek için aşağıdaki sorguyu kullanın: v$asm_diskgroup tan NAME,ALLOCATION_UNIT_SIZE i seçin; Optimal Veritabanı Kapsam Büyüklüklerini Ayarlayın ASM Ayırma Ünitesi Büyüklüğünü 4MB a ayarlayın bölümünde bahsedildiği gibi Oracle Exadata Storage Server, 4 MB lık bitişik birimlerde (contiguous chunks) tarama yaptığı zaman en iyi çalışır. Bunun veritabanı seviyesinde olduğundan emin olmak için veritabanı kapsam büyüklüğü en az 4MB olmalıdır. Bundan emin olmanın en kolay yolu en az 4MB lık birörnek kapsam büyüklükleriyle yerel olarak yönetilen tablo alanları (tablespaces) yaratmaktır. Bu strateji 4 MB lık veritabanı kapsamı yüzünden çok fazla alan israfına yol açarsa kapsam alan kullanımını INITIAL (İLK) ve NEXT (İLERİ) özellikleriyle segment seviyesinde kontrol edin. cell_partition_large_extents ile minimum kapsam büyüklüğünü bütün segmentlere otomatik tablo ayırma alanları için 8 MB lık bölünmüş nesneler ayarlayabilirsiniz. Aşağıdaki sorguyu kapsam büyüklüğü 4 MB tan küçük segmentler olup olmadığına bakmak için kullanın: select segment_name,partition_name from dba_extents where bytes < and owner = <schema name> ; Doğru Geçiş Stratejisini Seçin Oracle Exadata Storage Server a geçiş mantıksal ve fiziksel olarak yapılabilir. Kaynak veritabanı yukarda bahsedilen optimal kapsam büyüklüklerini içermiyorsa Tablo 1 i kullanarak en mantıklı geçiş stratejinizi belirleyiniz. Kaynak veritabanınız optimal kapsam büyüklüklerini içeriyorsa Tablo 2 yi kullanarak en iyi fiziksel geçiş stratejinizi belirleyiniz.

9 4. 5. Maksimum Mevcudiyet Mimarisi Tablo 1: Mantıksal Geçiş Stratejisi: Veritabanı Kapsamını Değiştirin Geçiş Stratejisi Oracle Exadata Storage Server üzerinde Yeni Tabloalanları yaratma Genellikle Veri ambarı müşterileri için idealdir. Oracle Logical Standby Genellikle minimal aksama süresi ve aynı kaynak/erek platform için idealdir. Oracle Streams ve Oracle Data Pump Genellikle minimal aksama süresi ve farklı kaynak/erek platform için idealdir. Oracle Data Pump Genellikle geçişi gerçekleştirmek için planlı bir bakım pencereniz olduğunda idealdir. Kaynak Veritabanı de Çalışıyor mu? ASM AU boyutun 4MB a ayarlayın Heterojen Platformları Destekleyin Zaman ve İşlemsel Yatırım Geçiş Hizmetinin Kesilme Zamanı Evet Evet Hayır En Düşük Kesintisiz Hayır Evet Hayır Orta Düşük4 Hayır Evet Evet Yüksek Düşük5 Hayır Evet Evet Düşük Yüksek 4 RMAN yedeklemeleri kullanıldığında, somutlama (instantiation) boyunca kaynak veritabanında hiçbir etki yoktur. 5 Kaynak veritabanı somutlama boyunca etkilenir. Etki kaç paralel işletim kullanıldığına bağlı olarak kontrol edilebilir.

10 c 6 m 7 Maksimum Mevcudiyet Mimarisi Tablo 2: Fiziksel Geçiş Stratejileri: Veritabanı Kapsam Büyüklüğünde Değime Yok Geçiş Stratejisi ASM Yedekleme Genellikle ASM yedekleme ve kaynak/erek versiyonu ile platform aynı olduğu zaman idealdir. Fiziksel Standby Veritabanı Genellikle aynı sürüm ve destekli çapraz platformlar için idealdir. Recovery Manager( Kurtarma Yöneticisi) Genellikle aynı kaynak/erek versiyon ile platformda tabloalanı seviyesinde geçiş yapıldığında idealdir. Taşınabilir Veritabanı Genellikle aynı son hane formatıyla farklı bir platform geçiş yapıldığında idealdir. Taşınabilir Tabloalanları Genellikle farklı platformlara, farklı son hane formatında ve farklı sürüme geçiş yapıldığında idealdir. Kaynak Veritabanı de Çalışıyor mu? ASM AU boyutun 4MB a ayarlayın Heterojen Platformları Destekleyin Mantıksal Geçişler-Veritabanı Kapsam Büyüklüğü Değişimi Zaman ve İşlemsel Yatırım Geçiş Hizmetinin Kesilme Zamanı Evet Hayır6 Hayır En Düşük Kesintisiz Evet Evet Sınırlı7 Düşük Düşük Evet Evet Hayır Düşük Orta Evet Evet Evet (aynı son haneli-same endian) Düşük Mantıksal geçiş kaynak veritabanından platforma bağımlı formata veri çıkarmadan oluşur. Bunu da kaynak veritabanına veri ekleme/yükleme takip etmektedir. Mantıksal geçiş aşağıdaki stratejilerden oluşmaktadır: Orta Hayır Evet Evet Orta Orta Oracle Exadata Storage Server üzerinde yeni tabloalanları oluşturma Mantıksal Standby Veritabanları Kullanarak Geçiş Yapma Oracle Streams ve Oracle Data Pump Kullanarak Geçiş Yapma Oracle Data Pump Kullanarak Geçiş Yapma 6 4 MB AU büyüklüğünü zaten kullanıyorsanız, ASM AU büyüklüğünü değiştirmemeniz hoş görülebilir. 7 Heterojen destek ile ilgili bilgi için OracleMetalink Not e bakınız.

11 Oracle Exadata Storage Server üzerinde Yeni Tabloalanları Yaratma Uygulamanız içsel olarak yeni verilerin mantıksal olarak içeri alınmasını ve eski verilerin dışarı atılmasını tabloalanı seviyesinde destekliyorsa,(bu Oracle Partitioning opsiyonuyla genellikle kullanılan bir stratejidir.) Oracle Exadata Storage Server ızgara diskleri içeren yeni ASM disk grubuna bütün yeni tablolalanlarını yaratarak Oracle Exadata Storage Server a geçin. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Sıfır uygulama kesintisine uğrar. Phased-in yaklaşımıyla daha az risk yaşar. Veritabanını hem mirasî depolamanın hem de Oracle Exadata Storage Server deposunun aşağıdakileri içermesini gerektirir: o Oracle Database çalışma sürümü yazılımı olmalıdır. o COMPATIBLE başlatma parametresi geçiş süreci başlamadan ye ayarlanmalıdır. Mantıksal Standby Veritabanları Kullanarak Geçiş Yapma Uygulama servis seviyesi anlaşmalarınız az ya da sıfır kesintiye izin veriyorsa, uygulamanızın çalışmasına müdahale etmeden veri taşıma, değişiklikleri izleme ve birleştirme işlemleri yapan Oracle Data Guard mantıksal standby veritabanı kullanın. Yüksek seviyede, bu çözüm öncelikle fiziksel standby veritabanını somutlaştırmakta, sonrasında onu mantıksal bir veritabanına dönüştürmekte ve son olarak eğer gerekliyse veritabanı kapsam büyüklüklerini mantıksal standby veritabanı üzerinde optimal büyüklüğe dönüştürmektedir 8. Bu stratejinin şu avantajları ve dezavantajları vardır: Somutlama sırasında fiziksel standby veritabanını somutlaştırmak için RMAN yedeklemeleri kullanarak kaynak veritabanı üzerindeki etkiyi ortadan kaldırabilirsiniz. Veri iki defa taşınır, bir defa ilk somutlamada, bir defa da mantıksal standby veritabanı için yapılan planlı bakımda. Kaynak veritabanını yükseltmenize gerek yoktur. Platform geçişi desteklenmez. Bu tasarlanması karmaşık bir çözümdür çünkü veri geçiş sırasında değişiyor; ama çok az kesinti faydasıyla geri dönüyor. Geçiş için Oracle Mantıksal Standby (Oracle Logical Standby) kullanımı ile ilgili daha fazla bilgi için OracleMetalink Not e bakınız. 8 Diğer değişiklikler de bu planlı bakım sırasında yapılabilir, fakat daha geniş kapsam büyüklükleri, Oracle Exadata Storage Server tarama performansı için daha önemlidir.

12 Oracle Streams ve Data Pump Kullanarak Geçiş Yapma Uygulama servis seviyesi anlaşmalarınız az ya da sıfır kesintiye izin veriyorsa, uygulamanızın çalışmasına müdahale etmeden veri taşıma, değişiklikleri izleme ve birleştirme işlemleri yapan Oracle Streams ile Oracle Data Pump ı kullanın. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: İlk somutlama sırasında kaynak veritabanı potansiyel olarak etkilenir. Kaynak veritabanı üzerindeki etkiyi kontrol edebilmek için somutlama yapan paralel süreçlerin sayısını sınırlandırın. Veri ilk somutlama sırasında bir defa taşınır. Kaynak veritabanını yükseltmenize gerek yoktur. Platform geçiş desteklenmektedir. Bu tasarlanması karmaşık bir çözümdür çünkü veri geçiş sırasında değişiyor; ama çok az kesinti faydasıyla geri dönüyor. Oracle Streams ile Oracle Data Pump çözümü ile ilgili daha fazla bilgi için Ek C deki Oracle Streams Kavramları ve Yönetimi[11] a bakınız. Oracle Data Pump Kullanarak Geçiş Yapma Uygulama servis seviyesi anlaşmalarınız, planlı bakım pencereniz açıkken bütün verileri taşımanız için yeterli kesinti izni verirse Oracle Data Pump ı mirasî depodan (legacy storage) Oracle Exadata Storage Server a verilerinizi büyük yığınlar halinde taşımak için kullanın. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Bu daha kolay bir çözümdür çünkü veri geçiş sırasında değişmiyor ve daha fazla kesintiye neden oluyor. Kaynak veritabanını yükseltmenize gerek yoktur. Platform geçiş desteklenmektedir. Oracle Data Pump veriyi veritabanı dışına hazırlama ihtiyacını ortadan kaldıran ağ getirme özelliğini sağlıyor. Bu özellik büyük bölünmüş tablolarla kullanıldığında QUERY (SORGU) parametresini birçok işten getirilen verileri ayırmak için kullanın. Böylece bütün mevcut hesaplama kapasitesi düzenlenebilir. Bu çözüm ile ilgili daha fazla bilgi için Oracle Database Utilities 11g Release 1 (11.1) deki Oracle Data Pump bölümünü okuyunuz. [8].

13 Fiziksel Geçişler-Veritabanı Kapsam Büyüklüğü Değişikliği Yapmadan Fiziksel geçiş, kaynaktan hedefe yapılan transferle takip edilen platforma bağlı veri çıkarmadan oluşur. Bazı durumlarda, veri dosyaları hedefe taşındıktan sonra dönüştürme işlemi çalıştırmanız gerekebilir. 9 Geçiş fiziksel seviyede yapıldığından, kaynak veritabanı optimal veritabanı kapsam büyüklüklerini içermiyor olabilir. Bu Optimal Veritabanı Kapsam Büyülüğünü Yapılandır bölümünde anlatılmaktadır. Performans en önemli önceliğinizse Veritabanı Kapsam Büyüklüğünü Değiştirmek için Mantıksal Geçişler bölümünde anlatılan teknikleri kullanın. ASM Yedeklemesi Kullanarak Geçiş Yapma başlığı hariç diğer bütün başlıklar veritabanı veya tabloalanı geçişlerini ele almaktadır. Birkaç istisna 10 hariç Oracle Exadata Storage Server a geçiş Oracle ASM e veritabanı veya tabloalanı geçişi ile aynıdır. Bu yüzden fiziksel veritabanı veya tabloalanı geçişleri için mevcut MAA white paper(beyaz kâğıt)ların en iyi yöntemlerinden faydalanabilirsiniz. Söz konusu kâğıttan çeşitli geçiş stratejilerini açıklayan aşağıdaki bölümlerde referans alınmıştır: geçiş stratejileri ASM Yedeklemesi Kullanarak Geçiş Yapma Fiziksel Standby Veritabanı Kullanarak Geçiş Yapma RMAN (Recovery Manager) Kullanarak Geçiş Yapma Taşınabilir Veritabanı Kullanarak Geçiş Yapma Taşınabilir Tabloalanı Kullanarak Geçiş Yapma ASM Yedeklemesi Kullanarak Geçiş Yapma Mirasi depolama (legacy stroage) için ASM normal veya yüksek yedekleme kullanıyorsanız, bütün disk grubunuzu hiçbir kesinti olmadan taşıyabilirsiniz. Bunu disk grubuna Oracle Exadata Storage Server deposu ekleyip disk grubundan mirasi depolamayı çıkararak ve CELL.SMART_SCAN_CAPABLE disk grubu özelliğini TRUE (DOĞRU) ya ayarlayarak yapabilirsiniz. İşlemi en ideal seviyeye taşımak için depoyu ASM örneğindeki tek komut olarak çıkarın ve ekleyin. Bu strateji için örnek akışı aşağıdaki gibi olacaktır: 1. 4 MB AU büyüklüğüyle normal veya yüksek yedekleme disk grubundaki mevcut mirasi disklerle başlayın. 1. RDBMS yazılım ve veritabanının Veritabanı Uyumluluğu bölümündeki uyumluluk gerekliliklerini desteklediğinden emin olun. 9 Mesela dönüştürme işlemi son hanede değişiklik varsa gerekli olabilir. 10 Sunucu yönünüzü OSSINIT.ORA/CELLIP.ORA dosyasına yapılandırmalısınız. ASM_DISKSTRING parametresi de Oracle Exadata Storage Server ızgara disklerine doğru yolu eklemenizi gerektirmektedir.(ya varsayılanı alarak ya da doğru yolu belirleyerek)

14 3. ASM yazılım ve disk gruplarının ASM Uyumluluğu bölümündeki uyumluluk gerekliliklerini desteklediğinden emin olun. İstisna olarak CELL.SMART_SCAN_CAPABLE=TRUE ayarlayın. CELL.SMART_SCAN_CAPABLE bu noktada FALSE(YANLIŞ) olarak ayarlayın. Çünkü mirasi diskler hala disk grubunda mevcutlar ve Exadata ızgara diskleri eğer TRUE(DOĞRU) ayarı yapılmışsa eklenemezler. 4. Yeni Exadata ızgara disklerini disk gruplarına ekleyin ve tek bir ASM ALTER DISKGROUP komutuyla mirasi diskleri disk grubundan kaldırın. Disk ekleyip çıkarmayı tek bir komutla yapma operasyonu daha verimli kılar be tek bir yeniden dengeleme gerekir. POWER (GÜÇ) sınırının Yeniden dengeleme sırasında kullanılan POWER (GÜÇ) sınırının SLA uygulamalarını etkilemediğinden emin olun. 5. Yeniden dengeleme bittiğinde hiçbir hatayla karşılaşmadığını ve bütün mirasi disklerin disk grubundan çıkarıldığını doğrulayın. BUNU ASM uyarı günlüğündeki yeniden dengelemenin başarıyla bittiği ile ilgili mesajları, diskleri kapatan önbelleği ve silinen disk başlıklarını kontrol ederek yapabilirisiniz. 6. Sonunda disk grubunda sadece Exadata diskleri kaldığında CELL.SMART_SCAN_CAPABLE i TRUE (DOĞRU) olarak ayarlayabilirsiniz. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Sıfır kesintiye neden olur. ASM sürümünün olmasını gerektirir. Platform geçişi desteklenmez. Uygulama etkisi POWER ayarını yeniden dengeleyerek kontrol edilebilir. Fiziksel Standby Veritabanı Kullanarak Geçiş Yapma Bu opsiyon için yüksek seviye stratejisi Oracle Exadata Storage Server da fiziksel standby veritabanı yaratmak ve geçiş için Data Guard sistem değişikliği (switchover) yapmaktır. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Bir dakika veya daha az bir kesintiye neden olur. Kaynak veritabanını sürümünü e yükseltmenizi gerektirir. Platform geçişi için sınırlı destek 11 Yeni bir DB_UNIQUE_NAME belirlemenizi gerektirir. Bu geçiş stratejisi ile ilgili daha fazla detay ASM ye Minimal Kesintili Geçiş için En İyi Yöntemler (Best Practices for Minimal Downtime Migration to ASM) [5] Başlıklı MAA white paper ında mevcuttur. 11 Heterojen des tile ilgili daha fazla bilgi için OracleMetalink Not a bakınız.

15 RMAN (Recovery Manager) Kullanarak Geçiş Yapma Bu opsiyon için yüksek seviye stratejisi ilk RMAN tam yedeklemelerini ve sonraki artımlı yedeklemeleri Oracle Exadata Storage Server üzerinde yaratmak ve RMAN switch-to-copy özelliğini geçiş için kullanmaktır. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Orijinal DB_UNIQUE_NAME korunur; yeni bir DB_UNIQUE_NAME gerekmez. Opsiyonel parçalı tabloalanı seviyesi geçişi. Kaynak veritabanının sürümünü e yükseltmeniz Platform geçişi desteklenmez. Fiziksel Standby Veritabanı Kullanarak Geçiş Yapma bölümünde anlatılandan daha fazla kesintiye neden olur. Özellikle switch-to-copy den önce, son artımlı yedekleme sırasındaki birçok güncelleme sırasında bu gibi kesintiler olur. Bu geçiş stratejisi ile ilgili daha fazla detay Oracle Database 10 g En İyi Yöntemler: Otomatik Depolama Yönetimi (ASM) ne Geçiş [4] başlıklı MAA white paper ında mevcuttur. Taşınabilir Veritabanı Kullanarak Geçiş Yapma Bu opsiyon için yüksek seviye stratejisi Taşınabilir Veritabanı özelliğini bütün veritabanını aynı son hane(endian) formatında farklı bir platforma taşımak için kullanmaktır. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Basit bir işlemsel çözüm sağlar. Kaynak ve erek veritabanlarında aynı son hane(endian) platformunu gerektirir. Kaynak veritabanınızın sürümünü ye yükseltmenizi gerektirir. Hedef platforma veriyi mevcut kılmak için kesinti gerektirir. Bu geçiş stratejisi ile ilgili daha fazla detay Taşınabilir Veritabanı Kullanarak Platform Geçişi Yapma [6] başlıklı MAA white paper ında mevcuttur. Taşınabilir Tabloalanları Kullanarak Geçiş Yapma Bu opsiyon için yüksek seviye stratejisi, tabloalanlarını taşımak için Taşınabilir Tabloalanları özelliğini kullanmaktır. Bu stratejinin aşağıdaki avantajları ve dezavantajları vardır: Kaynak ve erek üzerinde farklı son hane(endian) platformuna izin verir. Kaynak veritabanının yükseltilmesine gerek yoktur. Platform geçişi desteklenir. Tabloalanı seviyesinde parçalı veritabanı geçişlerine izin verir. Bu geçiş stratejisi ile ilgili daha fazla detay Taşınabilir Tabloalanı Kullanarak Platform Geçiş Yapma [7] başlıklı MAA white paper ında mevcuttur.

16 GEÇİŞ SONRASI EN İYİ YÖNTEMLER Geçişi tamamladıktan sonra aşağıdaki görevleri gerçekleştirin: Yeniden dengeleme için disk gruplarını kontrol edin Dizin gereklilikleri için değerlendirme yapın Yeniden Dengeleme İçin Disk Gruplarını Kontrol Edin ASM nin sorumluluklarından biri veritabanı verilerinin disk grubundaki bütün disklere eşit olarak dağıtıldığından emin olmaktır. Bu her ayırmadan veya yeniden ayırmadan sonra otomatik olarak olur. Bazen, bir disk grubu, bozuk bir yeniden dengeleme gibi beklenemeyen hatalardan dolayı dengesizleşebilir. Bu yüzden disk gruplarındaki dengeyi düzenli olarak kontrol etmek ve eğer gerekliyse elle yeniden dengelemeyi çalıştırmak işlemsel bir en iyi yöntemdir. OracleMetalink Not da disk grubunu kontrol etmek için bir betik (script) bulunmaktadır. Enterprise Manager Grid Control da disk grubu dengesi belirli bir eşiğin altına indiğinde uyarı vermektedir. Eşiği uyarlayabilirsiniz. Dizin Gereklilikleri için Değerlendirme Yapın Oracle Exadata Storage Server daki üstün tarama oranları, önceden mirasi depolama üzerinde iyi performans için gerekli olan dizinlerin gerekliliklerini ortadan kaldırmayı mümkün kılar. Dizinleri kullanan uygulama yürütme planlarının Oracle Exadata Storage Server taramalarıyla daha hızlı çalışıp çalışmadıklarını görmek için değerlendirme yapmalısınız. Tablo taramaları ve dizin hızlı tam taramalar Oracle Exadata Storage Server a boşaltılırlar. Böylece FULL ve INDEX_FFS ipuçlarını taramaları yapmak ve performansı değerlendirmek için kullanabilirsiniz.

17 REFERENCES 1. Oracle Maximum Availability Architecture (Maksimum Mevcudiyet Mimarisi) Web sitesi 2. Oracle Database High Availability Overview (Yüksek Mevcudiyet Genel Bakışı) (Part #B14210) 3. Oracle Database High Availability Best Practices (Yüksek Mevcudiyet En İyi Yöntemleri) (Part B25159) 4. Oracle Database 10g Migration to Automatic Storage Management 5. Best Practices for Minimal Downtime Migration to ASM Oracle 10g Release 2 withdg.pdf 6. Platform Migration using Transportable Database (Taşınabilir Veritabanı Kullanarak Platform Geçişi) MigrationTDB.pdf 7. Platform Migration using Transportable Tablespaces (Taşınabilir Tabloalanı Kullanarak Platform Geçişi MigrationTTS.pdf 8. Oracle Database Utilities 11g Release 1 (11.1) 9. Oracle Database Storage Administrator's Guide 11g Release 1 (11.1) Oracle Streams Concepts and Administration

18 Oracle Exadata Stroage Server a Geçmenin En İyi Yöntemleri Eylül 2008 Yazar: Michael Nowak, Katkıda Bulunanlar: Andrew Babb ve Douglas Utzig Oracle USA, Inc. World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Dünya Çapındaki Sorgulamalar İçin: Tel: Faks: oracle.com Telif hakkı 2008, Oracle. Tüm hakları saklıdır. Bu belge sadece bilgi verme amaçlı çıkarılmıştır. Bu belgedeki içerik haber vermeden değiştirilebilir. Bu belgenin hatasız olduğunun garantisi verilmemektedir. Başka bir garantiye veya şarta da tabii değildir. Bu ister sözlü olarak söylensin, ister hukuk önünde imalı olarak söylensin, bunların arasına imalı garantiler ve pazarlanabilirlik ya da özel amaçlara uygunluk şartları da dâhildir. Bu belgeyle ilgili herhangi bir yükümlülüğü özel olarak reddediyoruz. Bu belgeyle hiçbir kontrat mecburiyeti doğrudan veya dolaylı yolla oluşturulmamıştır. Önceden yazılı iznimiz olmadan bu belge hiçbir amaçla hiçbir yolla, elektronik veya mekanik olarak çoğaltılamaz ve yayılamaz. Oracle, JD Edwards, PeopleSoft, ve Siebel Oracle Corporation ın ve onun bağlantılarının sicilli ticari markalarıdır. Diğer isimler söz konusu sahiplerin ticari markaları olabilirler.