Dataguard Tarafındaki Datafile ler Nasıl Rename Edilir

Dataguard ortamları çoğu zaman donamım  gereksinimleri bakımından production ile birebir olamıyabiliyor (ki uygulamaların birçoğuda bu şekilde) gerek memory gerekse disk kapasiteleri bakımından dataguardın bağlı bulunduğu sunucular productiondan geride oluyor. Durum böyle olunca dataguard tarafını kontrol etmeden production ortamına eklenen datafile’ ler, DG tarafında create edilemediğinden hata alınıyor,  sonrasında MRP processesi artık DG tarafında çalışmadığından senkronizasyon duruyor.  Bu tarz bir durumla karşılaştığımızda neler yapmamız gerekeceğinden bahsetmek istiyorum.

Öncelikle böyle bir durumla karşılaştığımızda alert logda alacağımız hatayı görelim ;

Thu Jun 16 12:08:18 2011

MRP0: Background Managed Standby Recovery process started (test)

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1111

Thu Jun 16 12:08:23 2011

Errors in file /u01/oracle/test/bdump/test_mrp0_8661.trc:

ORA-01111: name for data file 32 is unknown – rename to correct file

ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′

ORA-01157: cannot identify/lock data file 32 – see DBWR trace file

ORA-01111: name for data file 32 is unknown – rename to correct file

ORA-01110: data file 32: /oracle/10g/dbs/UNNAMED00032′

Logdan da görüleceği üzere 32 nolu dbf, prod ortamına create edilmiş ancak ordaki dizin DG tarafında olmadığı için (benim örneğimde dizin var ama klasör yoktu)  bu datafile’ i dbf altına UNNAMED olarak atayarak MRP processesini sonlandırmış. Burada yapmamız gereken bu datafile’ leri prod ortamdan bağlı bulunduğu tablespace’ leri backup moda alarak DG tarafına kopyalamak ve rename etmek olacak. Adım adım gidelim ;

Production ortamda ;

Datafile’ in hangi tablespace’ e ait ise o tablespace’ i backup moda alıyorum.

ALTER TABLESPACE deneme BEGIN BACKUP;

Sonra ilgili dbf’ i DG tarafına scp (rcp veya ftp)  ile DG tarafına kopyalalıyoruz. Primary tarafındaki işlemlerin aksamaması için kopyalama biter bitmez Production da tablespace’ i backup moddan çıkartıyoruz.

ALTER TABLESPACE deneme END BACKUP;

Primary tarafındaki işimiz bu kadar, sonrasında DG tarafında recover işlemini durduruyoruz;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

DG’ da file management parametresini manual olacak şekilde set ediyoruz.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

Database mount modda değilse, kapatıp mount modda açıyoruz;

STARTUP MOUNT;

Hatalı olan dbf’i rename ediyoruz;

ALTER DATABASE RENAME FILE ‘/u01/ oradata/test01.dbf’ TO ‘/u01/oradata/standby/test01.dbf’;

Ve apply işlemini başlatabiliriz artık ;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

BU şekilde hatalı olarak oluşturulmuş başka datafile’ ler var ise sırası ile tüm datafile’ ler için aynı işlemler tekrar edilmelidir. Sorunlu datafile’ lerin listesi DG tarafına

Select name from v$datafile ;

Sorgusu ile select edildiğinde ilk hata veren dbf ‘ e ait bilgiler görüntülenecektir. Birini düzelttikden sonra apply başlatıldığında bu sefer diğeri için aynı hatayı verecek dolayısıyla yukarıdaki script artık ikinci hatalı olan datafile’ i gösteriyor olacaktır.

Production tarafında herhangi bir rename işlemi yapmadık , ki bunun nasıl yapılması  gerektiğinden daha önce bahsetmiştim.

http://www.kamilturkyilmaz.com/2010/10/03/datafile-%E2%80%98-in-adini-rename-etme-pathini-degistirme/

Kamil TÜRKYILMAZ 

http://www.kamilturkyilmaz.com/

CRONTAB: You are not Authorized to Use Cron. Sorry.

Crontab dba’ lerin kimi zaman eli ayağı olmaktadır. Crontab, windows’ daki schedule task gibi düşünülebilir, OS seviyesinde, bir takım işlerimizi joblara bağlamak istersek crontab’ dan faydalanırız. Crontab ile ilgili sık kullanılan komutların bazıları ve açıklamaları aşağıdaki gibidir;

crontab -e         = Crontab dosyasını editlemenizi yani joblarınızı tanımlamanızı sağlar,  Eğer daha önce hiç tanımlanmamışsa bu bu komutla create edebilirsiniz.

crontab -l          = Crontab içerisine tanımlanmış olan tüm jobları görüntüleminizi sağlar.
crontab -r         = Crontab dosyasını tamamiyle siler.
crontab -v         = Crontab dosyasını en son hangi userın editlediğini gösterir.

Crontab –e  dediğinizde aşağıdaki bir hata mesajı alırsanız, bu bulunduğunuz userın crontab’ ı editlemesine yetkisi olmadığı anlamına gelir.

”crontab: you are not authorized to use cron.  Sorry.”

Hangi user için crontab’ a yetki vermek istiyorsanız, yapmanız gerekenler;

Root userı ile sisteme bağlanıyoruz,

vi komutu ile /usr/lib/cron/cron.allow dosyasını editleyip içerisine istediğimiz kullanıcı adını yazıp kaydedip çıkıyoruz.

Dosya yok ise create edilmelidir. Sonrasında ilgili user ile sisteme giriş yapıp crontab’ ı kullanabilirsiniz.  Bu aşamadan sonra crontab –l ile crontabı görüntülemeye çalışmak istediğinizde aşağıdaki gibi bir mesaj alırsanız ;

crontab: can’t open your crontab file

Henüz oluşturulmuş bir crontabınız olmadığı anlamına gelirki crontab –e ile dosyayı  editleyebilirsiniz.

Kimi sistemler de

/etc/cron.allow

Dosyasına ilgili userı eklemeniz gerekebilir bilginiz olsun.

Kamil TÜRKYILMAZ 

http://www.kamilturkyilmaz.com/

ORA-12519:TNS:no appropriate service handler found

Merhaba,

Herhangi bir tool ile database’ e connect olmaya çalışırken tns-12518 gibi bir hata ile karşılaşırsanız bunun iki nedeni olabilir;

Birincisi, database’e yeni start komutu verilmiş veya shutdown komutu ile down olma sürecinde iken bağlanmaya çalışırsanız,

İkincisi database’ de initial parametresi olarak tanımlı olan processes değerine ulaşılmış ve siz üzerine yeni bir connection sağlamaya çalışır iseniz bu şekilde bir hata ile karşılaşırsınız.

Bu hatayı aldığınızda listener loglarına bakacak olursanız hatayı şu şekilde görebilirsiniz;

15-MAY-2011 09:00:00 * (CONNECT_DATA=(SID=test01)(CID=(PROGRAM=c:\oracle\product\11.2.0\bin\sqlplus.exe)(HOST=CLBINFAPP02)(USER=TEST))) * (ADDRESS=(PROTOCOL=tcp)(HOST =turkyilmaz)(PORT=4487)) * establish * test01 * 12519

TNS-12519: TNS:no appropriate service handler found

15-MAY-2011 09:00:15 * (CONNECT_DATA=(SID=test01)(CID=(PROGRAM= c:\oracle\product\11.2.0\bin\emagent.exe)(HOST=turkyilmaz)(USER=SYSTEM))) * (ADDRESS=(PROTOCOL=tcp)(HOST=turkyilmaz)(PORT=50057)) * establish * test01 * 12519

TNS-12519: TNS:no appropriate service handler found

Bu hatanın procesess parametresinden kaynaklanıp kaynaklanmadığını aşağıdaki  sorgu ile test edebilirsiniz ;

SQL> select * from v$resource_limit where resource_name='processes';

RESOURCE_NAME          CURRENT_UTILIZATION                              MAX_UTILIZATION INITIAL_AL  LIMIT_VALU

processes                                                                          177                                        200                200         200

Yukarıda bizim örneğimizdeki durum şu şekilde process parametremiz 200 olarak set edilmiş durumda,  şu anda 177 procesess var ve max proceses limitine ulaşıldığını görüyoruz.

Son olarak eğer bir startup veya shutdown sürecine denk gelmediyseniz, çözüm olarak procesess limit değerini artırabiliriz. Tabi artırmak istiyorsanız, özellikle database’ de belirlediğiniz procesess değerinin üzerine çıkılmasını istemiyor iseniz, hata alan kullanıcıların beklemekden başka bir seçenekleri yok J

Processes değeri artırmak için ;

alter system set processes=150 scope=spfile;

komutunu kullanabilirsiniz. Bu parametre dinamik bir parametre olmadığından dolayı, yeni değerin etkin olabilmesi için database’ in restart edilmesi gerekecektir. 

Kamil TÜRKYILMAZ 

www.kamilturkyilmaz.com

Maximum Datafile Size Nasıl Hesaplanır

Database’ de eklemiş olduğunuz datafile’ lerin aslında bir max size’ ı var. Yani isteseniz de belli bir değerin üstünde bir datafile create edemezsiniz. Bu maximum değer kullandığınız db_block_size parametresi ile doğru orantılıdır.

Örneğin db_block_size’ ınız 8 kb ise oluşturabileceğiniz maximum datafile size limitiniz

= ((4096*1024)-1))*8196 = 34376507388 bytes = 33570807,99 kb = 32783,99 mb ‘ dır.

Kendi ortamlarınız için aşağıdaki formülü kullanarak datafile’ leriniz alabileceği maximum size’ ı hesaplayabilirsiniz.

Hesaplanışı  = ((4096*1024)-1)) *db_block_size

Data detaylı bilgi için;

What is the Maximum Datafile Size Limit In an Oracle Database? [ID 804733.1]

dökümanını okuyabilirsiniz.

--

Maximum datafile size for a SmallFile Tablespace based on 10gR2 documentation would be:

Block Size    Maximum Datafile File Size
-----------     ---------------------------
2k                4194303 * 2k     = 8 GB
4k                4194303 * 4k     = 16 GB
8k                4194303 * 8k     = 32 GB
16k              4194303 * 16k   = 64 GB
32k              4194303 * 32k   = 128 GB

Maximum datafile size for a BigFile Tablespace based on 10gR2 documentation would be:

Block Size    Maximum Datafile File Size
-----------     ---------------------------
2k                 4294967295 * 2k     = 8 TB
4k                 4294967295 * 4k     = 16 TB
8k                 4294967295 * 8k     = 32 TB
16k               4294967295 * 16k   = 64 TB
32k               4294967295 * 32k   = 128 TB

804733.1

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com

Windows Security Log Analizi Eğitimi

Merhabalar,

Güvenliğin artık şirketler için vazgeçilemez bir noktada olduğunu biliyoruz.
Şirket içi çalışanlarının yapmış oldukları işlemlerin loglanması, kontrolüde bu kapsamda zaman zaman ciddi bir güvenlik açığı oluşturabiliyor. Bugün bu bahsetmiş olduğum güvenlik konusu ile ilgili olarak bir eğitim duyurusu yapmak istiyorum. Windows security log eğitimi, eğitim içeriğini aynı www.logyonetimi.com sitesinin kurucusu da olan Osman Bey organize ediyor. Konuyla ilgilenen veya ilgilenmek isteyen meraklı arkadaşlarımıza duyurulur.

Konuyla ilgili detaylı bilgiye aşağıdaki linkden ulaşabilirsiniz.

http://www.logyonetimi.com/web/Makaleler/11-05-27/Windows_Security_Log_Analizi_E%c4%9fitimi_-_3-146012777.aspx

Kamil TÜRKYILMAZ

www.kamilturkyilmaz.com