Step by Step creating a Physical Standby Database on 10gR2

Oracle’ ın dataguard ürünü disaster recovery senaryolarında önemli bir yer tutmaktadır. Dataguard basit mantıkla sizin productiondaki database’ inizin (belli kriterler altında) birebir eşleniğinin tutulmasını sağlar. Buda size production database’inizde bir problem olduğunda veya productionda yapacağınız bir patch geçişi veya upgrade operasyonunda kesintiye gerek bırakmadan işlem yapabilme imkanı sağlar. Dataguard kurulumlarında oracle versiyonlarındaki farklardan kaynaklanan bir takım farklılıklar olabilmektedir. Dolayısıyla bu tarz installion guide’ ları oluştururken versiyon bilgisi önemlidir.  Bu yazımda 10gR2 kurulu bir production sistemimiz üzerine physical standby database’ i nasıl kurabileceğimizden bahsedeceğim. Sonrasında da ayrı bir yazı ile aynı işlemi  11gR2 de içinde yazmayı planlıyorum.

Öncelikle dataguard kurabilmemiz için (10g için kıstlardan bahsediyoruz, 11g için kısıtlarda ciddi değişimler oldu) ön koşullar nedir ondan biraz bahsedelim. Kısıtlarımızı iki başlık altında toplayabiliriz. Continue reading

Oracle Initial Parametreleri

Oracle da database’ ini startup ile açmaya kalktığımız da instance ilk iş olarak parametre dosyasını okumaya çalışacaktır. Dolayısıyla temel initial parametrelerinden bahsederken bizim için çok kritik file’ lerimizden biri olan spfileSID.ora dosyasından da kısaca bahsedeceğiz.

Parametre dosyaları Linux’ da;  $ORACLE_HOME/dbs,  Windos’da $ORACLE_HOME/database  altında bulunur. Database create edilmesiyle birlikte spfileSID.ora dosyamızda oluşur.  Bunun yanısıra parametre değişikliğini database içirisinden Alter system veya Alter database ile yapmak istemediğimiz veya yapamadığımız durumlarda ise kullandığımız birde pfileSID.ora dosyamız olacaktır. Bu dosya db create operasyonu sonrasında oluşmaz, bunu create etmek için sql satırında; Continue reading

Canlı Bir Transportable Tablespace Operasyonu Örneği

Yazılarımdan da anlaşılacağı üzere bu aralar transportable tablespace’ le yakından ilgileniyorum. Bu konudaki yapmış olduğum tüm testleri ve production ortamlarımızda yapmış olduğumuz operasyonlarla ilgili detaylarıda sizinle buradan paylaşmaya çalışıyorum. Şimdiye kadar tranportable tablespace ile ilgili çalışma mantığından, kıstlarından bahsettik. Neden bu konu üzerine bu kadar yoğunlaştığımdan bahsedeyim, ileride sizlerde benzer bir durumla karşılaşırsanız diğer yöntemler ile karşılaştırmada yardımcı olacaktır. Production ortamda kullandığımız bazı database’ lerimizi yeni alınmış olan (yeni sunucu ibm p795 serisi) sunucular üzerine taşımaya çalışıyoruz. İlk taşınacak olan database yaklaşık 3 tb büyüklüğündeki bir database, bu database’ i migrate etme işini bitirdik. Bugün bu taşıma işlemini transportable tablespace yöntemi kullanarak nasıl yaptığımızdan step by step bahsedeceğim ; (Şunu belirtmemde fayda aşağıdaki stepler bizim taşımış olduğumuz database’ in özellikleri ile şekillenmiş adımlar yani bu database’ de materialized view yoktu, eğer olsaydı bir stepde bunun için olacaktı) Continue reading

Transportable Tablespace Yöntemi ile Taşınamayan Nesneler İle İlgili Bir Test

Bu aralar yaklaşık 19 tb büyüklüğündeki bir production database’ imizi farklı bir sunucu üzerine migration yapacağımız için kullanacağımız muhtemel yöntemleri ve bu yöntemlerin artılarını ve eksiklerini test etmekle uğraşıyorum. Transportable tablespace bu yöntemlerin en başında geliyor aslında, burdaki en büyük problemlerimizden biride database içerisindeki materialized views’ lerin durumu, zira transportable tablespace bu nesneleri taşımıyor. Bununla ilgili bugün yapmış olduğum bir testi sizlerle paylaşmak istedim. Continue reading