Datafile'ların Taşınması ve Disk Alanı Problemi

Merhaba,

Bugün yazacağım konu, Oracle'da bir fiziksel datafile'ı, başka bir dizin altına nasıl taşırız? Taşırken ne gibi şeylere dikkat etmek gerekiyor? Hangi datafile'ları taşırken veritabanını kapatmaya gerek var ya da yok?

Yapı itibariyle genelde karşılaşılan durumlardan birisi de Oracle'ın fiziksel veri dosyaları olan datafile'ların bulunduğu mount point'lerin dolmasıdır. Bu durumda ya yeni bir mount point açılır ve yeni datafile'lar buraya işlenir, ya da var olan datafile'ları başka bir alana taşırız. Bu taşıma işlemi sonrasında da %100'e ulaşmış olan mount point biraz rahat nefes almış olur.

Öncelikle şunu belirtmeliyim ki bir mount point datafile'larla dolmuş işe ve bunun içerisinde system tablespace'ine ait datafile'lar varsa, datafile'ları taşıyabilmek için mutlaka ve mutlaka veritabanını kapatmalıyız. Aynı durum sysaux ve undo tablespace için de geçerlidir. Erişimin Oracle'ın kendisi tarafından olan datafile'ları taşıyabilmenin yolu veritabanını kapatmaktır.

Bir örnek ile devam etmek gerekirse;

SQL> shutdown immediate;
# mv /db/oracle/data01/undotbs1.dbf /db/oracle/undo/undotbs1.dbf
SQL> startup mount --> mount aşamasına taşımamızın nedeni, datafile'lar alter database open komutu geldiği andan itibaren açılırlar. Bu aşamada control dosyamız okunmuş ve spfile içindeki parametrelerle veritabanı mount edilmiş olur.
SQL> alter database rename file /db/oracle/data01/undotbs1.dbf to /db/oracle/undo/undotbs1.dbf;
SQL> alter database open;

Yukarıdaki işlemden sonra sistem tablespace'imize ait datafile, başka bir alana kopyalanmış oldu.

Eğer kopyalayacağımız datafile başka bir tablespace'de ise sadece ilgili tablespace'i offline yaparak işlemimizi gerçekleştirebiliriz.

Örnek olarak;

SQL> alter tablespace USERS1 offline;
SQL> !mv /db/oracle/data01/users01.dbf /db/oracle/data12/users01.dbf
SQL> alter tablespace USERS1 rename datafile /db/oracle/data01/users01.dbf to /db/oracle/data12/users01.dbf;
SQL> alter tablespace USERS1 online;

Biraz daha garanti olsum işin derseniz eğer, mv komutu yerine cp komutu kullanarak, tablespace'i online yaptıktan sonra eski datafile'ı rahatlıkla silebilirsiniz.

Bu aşamada çok kritik bir noktadan bahsetmem gerekiyor. Bazı durumlarda Oracle, disk üzerindeki alanı bırakmaz ve fiziksel olarak datafile'ı taşısakta yerin hala %100 dolu olduğunu görebiliriz. Bu durumun sebebi işletim sistemi değildir. Çünkü dikkat ederseniz, bir datafile'ı shrink yaptığınız zaman yer açılacak ancak yukarıdaki örnekte olduğu gibi taşıdığınız zaman yer açılmayacaktır. Bunun tek sorumlusu olarak control dosyasını görebiliriz. control dosyası bu datafile'ın hala orada olduğu bilgisini tuttuğu için fiziksel olarak taşısakta ne yazık ki istediğimiz alan disk üzerinde açılmıyor. Nedenlerinden birisi ise datafile'ın bağlı olduğu tablespace'in bir takım kullanıcılar tarafından erişiliyor olması. Eğer Solaris kullanıyorsanız lsof 12 ; ile işletim sistemi seviyesinde kontrol ederseniz, farkına varacaksınız. İşletim sisteminiz HPUX, SUSE ya da Red-Hat tarzı bi linux tabanlı işletim sistemi ise program yüklemeniz gerekebilir.

Çözüm olarak veritabanını kapatıp, yeniden başlatmalıyız. Veritabanı yeniden başladığı zaman, bağlanacak yeni kullanıcılar datafile'ların yeni yerine erişebilmiş olacak. Dolayısıyla control dosyası da yenilenmiş olacak ve mount point'in disk alanını kontrol ettiğimiz zaman da açılan alanı görebileceğiz.

Biraz karmaşık olduğundan soru işaretlerinin oluştuğu yerde bana e-posta gönderebilirseniz memnuniyetle cevaplamak isterim.

İyi çalışmalar,

Ogan

TOAD verileri göstermiyor mu?

Merhaba,

Öncelikle yazımda bahsedeceğim hataların ne olduğundan bahsedeyim. Oracle'da alınabilecek hatalar arasında;

ORA-03120: iki görevli dönüştürme yordamı: tamsayı taşması
ORA-03116: dönüştürme yordamına geçersiz arabellek uzunluğu geçirildi
ORA-03115: desteklenmeyen ağ veri türü ya da temsilcisi
ORA-03106: teklikeli iki görevli iletişim protokolu hatası

Şimdi sorabilirsiniz, yukarıdaki oracle hatalarını neden yazdın diye. Birincisi ve en önemlisi bu hatalarla karşılaştığınız zaman google ya da metalink size çok fazla cevap veremeyecektir. Veremeyecektir çünkü aynı hataları ben de aldım ve Oracle'a SR açmama rağmen sonuca gidemediler.

Hataların anlamlarına baktığımız zaman bize çok fazla birşey ifade etmiyor. Bu hataları aldığınız zaman da hiçbir trace dosyası ya da alert.log'da herhangi sıradışı birşey görmüyor olacaksınız. Hatta ve hatta, listener.log, sqlnet.log vs. baktığınız zaman da herşey doğal görünecek. Ama siz TOAD veya 3ncü parti bir yazılımda verilerinizi göremek istediğinizde bu hataları alıyor olacaksınız. Evet, çıldırmamak elde değil, örneğin TOAD'da data kısmına tıklarsınız, bekler, bekler, bekler ve sonunda bu dört hatadan birisini yapıştırır. İşin kötü yanı, belli bir denemeden sonra da Oracle sizin bağlantınızı zorla düşürür ve tekrar bağlanmanız gerekir. Bu böyle sürer durur. Oracle'a SR açarsınız, sizden binlerce trace dosyası isterler, onu yap, bunu dene, olmadı mı? o zaman şunu da deneyelim derler. Ayrıca bu hatayı da sqlplus ile bağlandığınız zaman ve grafiksel bir arayüz kullanmadığınız zaman almayacaksınız da. Ne zaman grafiksel bir arayüz ile veri çekmek isterseniz ya da grafiksel arayüzünüz veritabanına bağlanmaya çalışırsa, bu hatalar gelebilir. Bu, sorunun 3ncü parti yazılımlarda olmadığını da gösteriyor denebilir.

Benim karşılaşdığım durum için, cevabı söylüyorum: VPN! Evet, VPN bağlantısı. VPN versiyon yükseltmesi olmadan önce çok güzel çalışan TOAD'ımız, versiyon yükseltmesinin ardından bu hataları vermeye başladı. İlk başta heryere baktık, herşeyi yaptık ancak sonuç alamayınca başka yerlere yöneldik. Sonuçta hatayı aldığımız zaman ile VPN'in versiyonunun yükseltildiği zaman aynı çıktı! Bağlantı methodumuzu "SSL VPN" ile web üzerinden bağlanacak şekilde değiştirdiğimiz zamansa problem kalmadı!

Benim bu hatalarla karşılaştığım yegane durum VPN ile ilgili olduğu için umarım bu sorun ile karşılaşıyorsanız, sizin de probleminiz VPN olur. Versiyon yükseltmesi yapıldıktan sonra hiçbir VPN parametresi veya kuralı değiştirilmeli, değiştirilecekse de mutlaka Oracle veritabanı yöneticisine bildirilmelidir. VPN dışında bu sorun ile karşılaşan ve hala aynı sorunu yaşanlar olabilir, onlara da benimle irtibata geçmeleri konusunda ricada bulunmak istiyorum.

Bu hataları google ya da metalink'te arattığınız zaman çıkan sonuçların genelinde bir cevap yok ya da Oracle desteği ile irtibata geçin cevabı var. Bu yazıyı okuyan ve aynı sorunlara sahip olan insanlar varsa, lütfen Oracle'a SR falan açmadan önce bağlantı ayarlarını kontrol ediniz, VPN ayalarına, kurallarına ve parametrelerine bakınız.

Bu konu ile ilgili çok fazla Türkçe forum ya da cevap olmadığı ve Türkiye'de başka insanlarında mustarip olduğunu bildiğim için yazı yazdım. Daha detaylı soru sormak ya da danışmak isterseniz; oganozdogan@gmail.com adresine mail atabilirsiniz.

İyi çalışmalar,

Ogan

Oracle Görevleri Sonlanıyor!..

Merhaba,

Oracle'da pek sık rastlanmasa da birgün başımıza gelme olasılığı yüksek ancak geldiği zaman da son derece can sıkıcı olabilen bir hatadır Oracle görevlerinin zamanla sonlanması.

Örneğin 10gR2 veritabanımız var ve job_queue_process parametremiz de 50 olarak tanımlanmış. Bir takım görevler yaratıyoruz ve bu görevler rutin olarak her gece, her saat ve hatta her dakika çalışıyor. Ancak birgün bakıyorsunuz ki, tanımladığınız görevler 2 gündür çalışmıyor! Elle çalıştırıyorsunuz, o zaman çalışıyor ama otomatik olarak tetiklenmiyor. Hemen dönüp unix sisteme "ps -ef grep ora" yazıyorsunuz ve karşınıza hiç "ora_j001" ya da "ora_j***" tipinde çıktılar gelmiyor. Bütün arka planda çalışan görevleriniz şu anda ölmüş durumda! Şunu da belirtmeliyim ki bu sorun 9i ve 10g'de ortaya çıkmaktadır ve herhangi bir OS platformunda gerçekleşebilir.

Yapılabilecek çözümleri sıralıyorum;

1) Veritabanınız restricted modda olabilir mi?
select instance_name, logins from v$instance;
eğer logins=restricted ise:
alter system disable restricted session;

2) job_queue_processes > 0 mı?
show parameter job_queue_processes;
job_queue_processes parametresi 0 ise hiçbir görev çalışmayacaktır.

3) _system_trig_enable=false durumda mı?
select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv bwhere a.indx=b.indx and ksppinm='_system_trig_enabled';
eğer bu değer "false" ise:
alter system set "_system_trig_enable"=TRUE scope=both;

4) Görev kullanım dışı olmuş olabilir mi?
select job, broken, from dba_jobs where job=;
eğer kullanım dışı kalmış ise, alert log dosyasını ve trace dosyalarını incelemenizde fayda olacaktır.

5) Görev commit edilmiş mi?
Yarattığınız görevin script'inin içinde commit; aşaması yoksa, eklemeniz gerekebilir.

6) UPTIME > 497 ?
eğer OS uptime parametresi 497'den büyükse bu bir bug olabilir.(Metalink unpublished bug: 3427424)

7) DBA_JOBS_RUNNING
select * from dba_jobs_running;
görevin koşup, koşmadığına bakabilirsiniz.

8) LAST_DATE ve NEXT_DATE
select Job,Next_date,Last_date from dba_jobs where job=;
last_date ve next_date değerleri anlamsız olabilir.

9) NEXT_DATE ve INTERVAL
select Job,Interval,Next_date,Last_date from dba_jobs where job=;
Bu değerin de doğru olup olmadığını incelemek gerekiyor.

10) JOB_QUEUE_PROCESSES
En mantıklı ancak geçici sonuç olarak:
alter system set job_queue_processes = 0 scope=both;
alter system set job_queue_processes = 10 scope=both;
yaparsak eğer, bütün görevler baştan ve otomatik olarak başlayacaktır. Bu işleme CJQ işleminin yeniden başlatılması da denebilir.

11) DBMS_IJOB
Veritabanını yeniden başlatabilir ya da:
exec dbms_ijob.set_enabled(true); yapabilirsiniz.

Bu arada yukarıda sıralanmış bilgiler metalink'te 313102.1 döküman id'si aratılarak İngilizce olarak bulunabilir.

Bu durumda da hala otomatik olarak çalışmıyorsa -ki 10nuncu maddeden sonra çalışması gerekiyor- mutlaka ve mutlaka SR (Service Request) açmanız gerekiyor. SR aşamasında oluşan trace dosyaları ve alert dosyasını da isteyebilirler, muhafaza edilmesi çok önemli.

İyi akşamlar,

Ogan