Rman ile backup başlattım. Ne kadar sürecek?

select SID, START_TIME,TOTALWORK, sofar, (sofar/totalwork) * 100 done, sysdate + TIME_REMAINING/3600/24 end_at from v$session_longops where totalwork > sofar AND opname NOT LIKE '%aggregate%' AND opname like 'RMAN%'

Ne zaman Goldengate, Ne zaman Dataguard?

Goldengate, CEO 'su Türk bir şirket olarak, gelişmiş replikasyon teknolojileri
ile pazar lideri konumunda iken 2009 senesinde Oracle tarafından satın alınan
şirketin ismidir.

Peki ne işe yarar bu Goldengate?
--------------------------------

Goldengate, pek çok veritabanını(Oracle, DB2, Mysql, Sql) destekleyen bir
veritabanları arası veri aktarım çözümüdür. Primary veritabanınızdan
sizin belirlediğin tablo datalarını ve hatta DDL işlemlerini ikinci bir ayrı
veritabanına eş zamanlıya çok yakın bir şekilde işler.

Peki buna ne gerek var?
-----------------------

1) Yüksek kaynak tüketen sorgulardaki kaynak datayı barındıran
tablolar, Goldengate kullanılarak eş zamanlı olarak diğer bir veritabanına
kaydedilebilir ve burada rapor sorguları çalıştırılır. Böylece ana sistem üzerindeki
yük önemli ölçüde azalabilir.
2) Oracle BI veya benzeri bir çözüm kullanıyorsanız, raporlarınız önceki
gün datası ile değil şu anki data ile çalışabilir.
3) Önemli tablolarınızı Goldengate ile eş zamanlı olarak ikinci bir veritabanına
kaydederek backup politikanızı güçlendirebilirsiniz.
4) Bu çözümü kullanarak hiç ana veritabanınızı kapatmadan upgrade/migration mümkün olabilir.

Disaster Recovery(DR) ve Goldengate
-------------------------------------

DR durumuna kısaca veritabanınızı bir şekilde kaybetmek ve verilerimize
ulaşamaz hale gelmemiz diyebiliriz.(Donanım sorunu, kullanıcı hatası vs.)
Oracle Goldengate, DR konusunda Oracle Dataguard' ı tamamlayıcı veya destekleyici bir ürün olmakla
birlikte bana göre tek başına bu görevi üstlenmek için yeterli değil.

Çünkü;
1) Standby database Read-Write operasyonlarına açık olduğundan
birinin gidip bir şekilde verinizi değiştirme ihtimali vardır.
2) Karmaşık konfigürasyonu uzun sürer, her tablo için tek tek uğraşmak gerekebilir.
3) Oracle Dataguard gibi stabil ve bakım gerektirmeyen bir yapıya sahip değildir.
Örneğin konfigurasyonunuza bağlı olarak, primary database üzerinde
replike ettiğiniz tablolardan birisine bir alan eklersiniz ve replikasyonunuz duruverir.
Yeni bir tablo ekleyeceğiniz zaman yeniden konfigurasyon sürecine girersiniz.
4) Her türlü veri tipini ve tüm şemalardaki veriyi replike etmeyi desteklemez.
Yani database' inizin bire bir aynısını yedeklemiş olmazsınız aslında.
5) Ana veritabanınızı kaybetmeniz durumunda veritabanınızı hızlı bir şekilde
açmanız mümkün olmayabilir. (Örneğin performans ve aktarım sorunları nedeniyle constrait'leri
kapatmış olabilirsiniz veya triggerlarınız kapalı durumda olabilir.)

Buna karşın Dataguard,
1) Oracle' ın yıllardır kendini kanıtlamış, çok stabil çalışan DR çözümüdür.
2) Yukarıdaki Goldengate 'te bulunan DR dez avantajlarının hiç birisini içermez.
3) Goldengate ile kıyaslandığında çok daha performanslı çalışır çünkü aktarılan veri SQl
deyimleri değil değişen veri bloklarıdır.
4) Birkaç sql komutu çalıştırılarak standby database saniyeler içerisinde açılabilir.

Raporlama ve Dataguard
--------------------------

Oracle 11g' ye kadar, dataguard kullanılarak oluşturulan standby veritabanları kapalı durumdaydılar.
Yani primary database üzerinden değişiklikler anlık olarak geliyor ve uygulanıyordu ancak
siz standby database üzerinde sorgu çalıştıramıyordunuz. 11g ile gelen Active Dataguard özelliği,
aynı anda primary veritabanından gelen değişikler kaydedilirken, sorgulama yapmaya izin vermektedir.
Ancak Goldengate 'te olduğu gibi mesela yeni tablolar ekleyemezsiniz.


Özet;

Hem Oracle Goldengate hem de Oracle Dataguard çok güçlü özellikler barındıran ürünlerdir.
Fakat iyi sonuçlar almak için doğru ürünü doğru noktada kullanmalısınız.

Real time veri transferi konusunda GoldenGate çok başarılı bir çözüm sunmaktadır ve
DR konusunda bana göre vasat bir çözümdür. Dataguard ise Oracle to Oracle DR konusunda
çok başarılı bir çözümken raporlama konusunda ortalama bir çözümdür bence.

Goldengate kullanan arkadaşların yorumlarını bekliyorum.

İyi çalışmalar.

Sık kullandığım linux komutları -1

 

Linux komutlarının pek çok parametresi vardır.Burada benim sık kullandığım şekilleri yer alıyor.

df -h

Disk partition 'ları için doluluk oranlarını gösterir.

df komutunun -h parametresi, çıktının daha kolay okunabilir şekilde olmasını sağlar.
Büyüklük değerleri MB ,GB cinsinden görüntülenir. Eğer -h parametresi kullanılmaz ise
çıktıdaki büyüklükler kb cinsinden olacaktır.

Çıktıdaki sütunların açıklamaları aşağıdaki gibidir.

Filesystem : Dosya sistemi
Size : Toplam kullanılabilir alan
Used : Toplan kullanılan alan
Avail : Toplam boş alan
Use % : Kullanılan alan yüzdesi
Mounted on : Mount edildiği yer

du -hs *

Bir klasörün büyüklüğünü, alt dizinleri ile beraber hesaplar.

Bu komut bulunulan klasör altındaki tüm klasör büyüklüklerini hesaplayarak görüntüleyecektir.

find . -size +100M *

Bulunulan dizin içerisinde, alt dizinlerle beraber 100Mb 'dan büyük
dosyaları görüntüler. Tabi burada komutta değişiklik yaparak mesela 50MB' dan büyük dosyalarda
görüntülenebilir.

Oracle için database trigger

Trigger 'ların database seviyesinde kullanımı da mümkündür.
Aşağıdaki trigger; database içerisindeki 'SCHEMA_ADI'.'TABLO_ADI'
üzerinde her "alter" işlemi yapan DDL statement 'i çalıştığında tetiklenecek
ve hata görüntüleyerek yapılmaya çalışılan alter işlemini iptal edecektir.

CREATE OR REPLACE TRIGGER SYS.BENIM_TRIGGER
BEFORE ALTER
ON DATABASE
DECLARE
tmpVar NUMBER;
BEGIN
IF ora_dict_obj_owner = 'SCHEMA_ADI' and ora_dict_obj_name='TABLO_ADI' THEN
raise_application_error(-20100,ora_dict_obj_name||' uzerinde Alter operasyonu yasak.');
END IF;
END ;

Burada kullanılan trigger attribute 'ları ile ilgili açıklama aşağıdaki gibidir.

ora_dict_obj_owner : DDL hedefindeki object hangi user' a ait?
ora_dict_obj_name : DDL hedefindeki object ismi ne?

Daha fazla bilgi için aşağıdaki bağlantıyı ziyaret edebilirsiniz.

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28370/triggers.htm#CHDCFDJG

Oracle parametre dosyası hakkında

Parametre dosyası, Oracle başlangıç parametrelerini set eden dosyadır.
Parametre dosyası olmadan database başlatılamaz.

Database oluşturulduğunda, database oluşturma işleminin bir parçası olarak,
otomatik olarak oluşturulurlar. Genellikle çok az sayıda parametre değişikliği gerekli olur.
Verilen ilk değerler (default değerler) çoğu parametre için yeterlidir.
Değişikliğe gerek olmaz.

Parametre dosyası iki türlü olabilir. SPFILE ve PFILE.
Default olarak gelen ve tavsiye edilen parametre dosyası türü SPFILE 'dir.

PFILE
---------------------------
Genellikle init(SID).ora şeklinde isimlendirilir. Burada SID(Oracle system ID), database ismi anlamına

gelmektedir. PFILE sadece database başlatılırken okunur. Sonrasında PFILE üzerinde
yapılan değişiklikler, bir sonraki database yeniden başlatma işlemine kadar yeniden okunmaz.

Dezavantajları;
- PFILE dosyası file system içerisinde tutulur. Text editör kullanarak
değişiklik yapmak için file system erişimi zorunludur. Bu erişim bazı durumlarda güvenlik nedeniyle uygun bulunmayabilir.

- Dinamik değişikliklerin kalıcı olması isteniyorsa ,bu dosyaların da edit edilmesi zorunludur.

- RMAN, pfile dosyasının yedeğini almaz, dolayısıyla backup için bir ek prosedür gereklidir.


SPFILE
---------------------------
Genellikle spfile(SID).ora şeklinde isimlendirilir.
Oracle 9.0.1 ve sonrasında parametre dosyası olarak SPFILE kullanımı seçeneği eklenmiştir. Bu dosya binary bir dosyadır ve sadece SQL cümlecikleri ile üzerinde değişiklik yapılabilir.



EM (Oracle Enterprise Manager) veya ALTER SYSTEM deyimi kullanılarak
SPFILE üzerinde değişiklik yapılabilir. Bu şekilde sadece çalışan database, sadece SPFILE veya hem çalışan database hem SPFILE üzerinde aynı anda değişikli yapılabilir.
Örneğin;

- Sadece çalışan database instance için
ALTER SYSTEM SET open_cursors=300 SCOPE=MEMORY;

- Sadece SPFILE için
ALTER SYSTEM SET open_cursors=300 SCOPE=SPFILE;

- Hem çalışan database hem de SPFILE için
ALTER SYSTEM SET open_cursors=300 SCOPE=BOTH;

şeklinde SQL deyimleri çalıştırılabilir.

SPFILE türündeki parametre dosyaları pek çok avantaja sahiptir.

- ALTER SYSTEM deyimi kullanarak değişiklik yapılabilir. İşletim sistemine ulaşıp, ilgili dosyayı edit etme gerekliliği yoktur.

- İstenen bir parametre değeri, tek satılık SQL deyimi ile hem çalışan database için kullanılmak üzere, hem de SPFILE dosyasına kaydedilerek bir sonraki database start işleminde devreye alınmak üzere SPFILE dosyasına kaydedilebilir.

- RMAN, SPFILE dosyasının yedeğini alabilir. Ayrıca bu konunun takibi gerekli olmaz.

Database başlatma anı ve Parametre dosyası ilişkisi
----------------------------------------------------
Oracle, başlatma anında, SPFILE türü parametre dosyasını öncelikli olarak aramaktadır. Parametre dosyasının bulunduğu klasör aksi belirtilmedikçe aşağıda gösterilen yerdedir.

- Windows : $ORACLE_HOME/database
- Linux : $ORACLE_HOME/dbs

Database başlatma anında parametre klasöründeki dosyalar, parametre dosyasını bulmak için aşağıdaki sırayla taranır.

1) spfileSID.ora

2) spfile.ora

3) initSID.ora

4) init.ora

Eğer yukarıda dosyaların herhangibirisi bulunamadı ise database başlatılamaz ve
bu konuda hata görüntülenir.

Alternatif olarak, "startup" komutuna PFILE dosya yerini parametre olarak verebilirsiniz.

SQL> startup pfile=/path/to/pfile/inittestdb.ora

Kaynak
--------------------------
http://www.orafaq.com/node/5
http://www.dba-oracle.com/concepts/pfile_spfile.htm

IFS - Centura debug videosu download adresi güncelleme

Aşağıdaki adresten download edilebilir.

http://rapidshare.com/files/448429217/centura_debug.rar

MySQL-Data klasörünün değiştirilmesi

Çeşitli amaçlarla data klasörünü değiştirmek isteyebilirsiniz.
Ben aşağıdaki gibi bir durumla karşılaştım mesela.

Linux üzerine rpm kurarak mysql server kurduysanız
kurulumun bir parçası olarak "mysql" isminde
bir linux user oluşturulur ve mysql data klasörü
"/var/lib/mysql" klasörü olarak konumlanır.
Bu nedenle de "/var/lib/mysql" altındaki her bir ayrı klasör, ayrı bir database olarak görünür. Bu durum bir miktar sorunu da beraberinde
getirmektedir. Örneğin user a ait desktop verileri Linux işletim
sistemi tarafından "/var/lib/mysql/desktop" klasöründe saklanabilir.
Fakat mysqld, data klasörü olan "/var/lib/mysql" altında bulduğu "desktop"
ismindeki bu klasörün invalid bir database olduğunu varsayar.

Sorun aşağıdaki komutla da tespit edilebilir.

mysql> show databases;

Bu durumu düzeltmek için aşağıdaki adımlar uygulanarak
mysql data klasörü değiştirilir.

1) "mysql" user ı ile database kapatılır.

$ /etc/init.d/mysql stop

2) "root" user ile yeni mysql data klasoru oluşturulur ve
"mysql" user ına bu klasör için yetki verilir.

# mkdir /mysql
# mkdir /mysql/data
# chown -R mysql /mysql/data

3) Aşağıdaki satır, "/var/lib/mysql/my.cnf" dosyasına, "[mysqld]"
etiketi altına eklenir.

datadir=/mysql/data

4) "/var/lib/mysql" klasörü altında bulunan, my.cnf ve işletim sistemi ile ilişkili
dosya ve klasörler hariç tüm dosya ve klasörler "mysql" user ı ile
"/mysql/data" klasörüne taşınır.

5) Database açılır.

/etc/init.d/mysql start

Yukarıdaki adımları mysql 5.1.48 - redhat ile test ettim.
Bir sorun olması durumunda, aksi my.cnf dosyasında belirtilmedikçe
data klasöründe bulunan, "err" uzantılı error log
dosyasını inceleyebilirsiniz.