Oracle shared server opsiyonu ve IFS

Geçenlerde, IFS ERP uzmanı olarak çalışmaya devam eden arkadaşlarımdan birisi aradı.
Garip bir sorunundan bahsetti.

Problem oluşan sistem özellikleri
----------------------------------------
windows 2008 server 32 bit
8 gb ram
100+ acık kullanıcı connection
vs.

Problem Açıklaması
----------------------------------------
Database e belirli bir sayı üstü kullanıcı bağlandığında sistem yeni connection isteklerine
cevap vermiyormuş. Ta ki bazı connectionlar kapatılıncaya kadar.
Bu sorun oluştuğu anda ise sistem ram inin 2.6 gb gibi bir kısmı yani yarıdan az kısmı kullanılıyormuş.


Hımmm.

Oracle database e bağlanma sürecine biraz daha yakından bakacak olursak;

Oracle listener, her dedicated session için server tarafında bir dedicated server process
oluşturur(veya oluşturmaya çalışır). Bu oluşturulan process belirli miktarda bellek kullanır.
32 bit işletim sistemlerinde oracle, 2.5-3 gb civarının üstünde ram
kullanamadığından bu sorun oluşuyor. (2.5 - 3 gb den fazla ram kullanamama sorunu,
oracle dan değil 32 bit mimariden kaynaklanıyor yanlış anlaşılmasın )

Şimdi bir kere en iyi çözüm 64 bit işletim sistemine oracle kurmak ve gerekiyorsa sisteme ram eklemek.
Sonrada gerekli Oracle memory parametrelerini set etmek.

İkinci en iyi çözüm shared server opsiyonunu aktifleştirmek. Çünkü bu şekilde
her yeni connection için yeni bir dedicated server açılmayacak. Dolayısıyla memory
dolmayacak. Ama yoğun data kullanan kullanıcıların biraz daha yavaş çalışması duruma göre söz konusu.

Peki IFS ortamında nasıl yaparız bu
oracle shared server ı aktifleştirme işini?
------------------------------------------
1) Server parametrelerinde değişiklikler

alter system set shared_servers=10;
alter system set dispatchers='(PROTOCOL=TCP)';

Yukarıdaki sql statement lerini çalıştırdıktan bir süre sonra tns yöntemi dışı tüm bağlantılar
shared olmaya başlayacaktır.

Bu durumu aşağıdaki query ile de inceleyebilirsiniz.
SERVER sütünu SHARED ve NONE olan bağlantılar shared bağlantılardır.

select username,server from v$session order by server desc

Oracle parametrelerini burada sadece memory ye set ettik yani
database restart ında shared server konfigurasyonumuz yok olacak.
Parametrelerin kalıcı olması için testlerin ardından parametre dosyası güncellenebilir.

2) Client tarafında değişiklikler

IFS teki(Centura desek daha doğru) bağlantı tanımları runtime klasörü altındaki sql.ini dosyasından yapılıyor.
Bu dosya içerisinde, [oragtwy] tiketi altındaki remotedbname değerleri
bizim database bağlantılarımız.Örneğin sql.ini dosyamız aşağıdaki gibi olsun.

[oragtwy]
longbuffer=32760
fetchrow=20
maperror=OFF
substitute=SYSSQL.,
remotedbname=gercek,@//bizim_server_name_veya_ip:1521/bizim_sid

yukarıdaki 1. adımdaki server parametreleri set edildikten sonra,
buradaki "gercek" bağlantısından bağlanan tüm yeni client bağlantıları,
shared server connection u açarlar.

Burada bir sorun var .Tüm kullanıcı bağlantıları shared oldu. Fakat ben
bazı kullanıcılarımın performans açısından shared değil dedicated bağlanmasını
istiyorum diyebilirsiniz.

İşte bunu sağlayabilmek için sql.ini dosyasındaki, remotedbname imizi aşağıdaki
gibi değiştirmeliyiz.

remotedbname=gercek,@//bizim_sid

Buradaki bizim_sid, tnsnames.ora dosyasındaki tns ismidir.

Bu noktadan sonra bağlantının shared veya dedicated olması oracle client tnsnames dosyasına bağlıdır.

Dedicated için, aşağıdaki gibi bir tnsnames.ora tanımlaması olabilir.
Burada "SERVER=dedicated" olan bölümü "SERVER=shared" yaparsak bağlantı shared oluşturulmaya çalışılır..
Böylece her kullanıcıya, kendini bilgisayarıdaki tnsnames.ora da gerekli ayarları yaparak,
shared mı yoksa dedicated mı bağlantı yapacağı tanımlanabilir.

bizim_sid=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=bizim_server_name_veya_ip)
(PORT=1521)
)
(CONNECT_DATA=
(SERVER=dedicated)
(SID=BIZIM_SID)
)
)


Burada anlattıklarıma temel olan oracle versiyonları 10g ve 11g.
Ayrıca ASMM(Automatic Shared Memory Management 10g) veya
AMM(AutomaticMemory Managemet 11g) özelliklerinin aktif olduğunu varsaydım.
Bu varsayımımım yanlışsa, large_pool değerinin 50 mb civarı olarak, shared server konfigurasyonundan önce
ayarlanması gereklidir.Bu değer de duruma göre arttırılabilir.

Daha eski versiyonlar için farklı database configurasyonu gerekli olabilir.

Daha fazla bilgi için aşağıdaki bağlantılar da incelenebilir.

http://barisakverdi.blogspot.com/2010/10/oracle-shared-server-opsiyonu.html
http://barisakverdi.blogspot.com/2010/10/oracle-shared-server-konfigurasyonu.html
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc001.htm
http://download.oracle.com/docs/cd/B10500_01/network.920/a96580/connect.htm
http://download.oracle.com/docs/cd/B10500_01/network.920/a96580/mts.htm
http://www.dba-oracle.com/t_mts_multithreaded_servers_shared.htm

Kaynak: http://barisakverdi.blogspot.com/search/label/Centura

Detaylar

Bir tablo üzerinde kayıt varsa güncelleme yoksa ekleme yapmak

Oracle’da merge kelimesini kullanarak tek sql ile kayıt varsa güncelleme yoksa ekleme yaptırabiliriz (Upsert).
Upsert Sql’imiz:

 merge into tablo t
 using dual s on (t.alan1=1)
 when matched then
   update set alan2='UPDATE'
 when not matched then
   insert (alan1,alan2) values (1,'INSERT');

Test ediyoruz :


SQL> create table tablo (alan1 number(10),alan2 varchar2(10));
Table created
SQL> select * from tablo;
      ALAN1 ALAN2
----------- ----------
SQL> merge into tablo t
2 using dual s on (t.alan1=1)
3 when matched then
4 update set alan2='UPDATE'
5 when not matched then
6 insert (alan1,alan2) values (1,'INSERT');
Done
SQL> select * from tablo;
      ALAN1 ALAN2
----------- ----------
          1 INSERT
SQL> merge into tablo t
2 using dual s on (t.alan1=1)
3 when matched then
4 update set alan2='UPDATE'
5 when not matched then
6 insert (alan1,alan2) values (1,'INSERT');
Done
SQL> select * from tablo;
      ALAN1 ALAN2
----------- ----------
          1 UPDATE
SQL> commit;
Commit complete
SQL>

Detaylar

Oracle’da sql ile bakiye hesaplama

Oracle’da analitik fonksiyonları kullanarak bakiye hesaplanabilmektedir. Örneğimizde bakiye test tablosu oluşturup test verilerini giriyoruz. Hesaplama sutunu için SUM grup fonksiyonunu OVER ile kullanarak satır satır çalışmasını sağlıyoruz. ORDER BY ile toplama işlemini hangi sırayla yapılmasını gerektiğini belirtiyoruz.


create table bakiye_test (
  id number primary key,
  tarih date not null,
  giren number not null,
  cikan number not null
);

insert into bakiye_test values (1,'05.04.2010',100,0);
insert into bakiye_test values (2,'07.04.2010',0,200);
insert into bakiye_test values (3,'09.04.2010',300,0);
insert into bakiye_test values (4,'10.04.2010',100,0);
insert into bakiye_test values (5,'12.04.2010',0,50);
insert into bakiye_test values (6,'19.04.2010',50,0);
insert into bakiye_test values (7,'21.04.2010',0,30);
commit;

SQL> SELECT B.*, SUM( GIREN-CIKAN ) OVER (ORDER BY TARIH ASC ) BAKIYE FROM BAKIYE_TEST B;
        ID TARIH            GIREN      CIKAN     BAKIYE
---------- ----------- ---------- ---------- ----------
         1 05.04.2010         100          0        100
         2 07.04.2010           0        200       -100
         3 09.04.2010         300          0        200
         4 10.04.2010         100          0        300
         5 12.04.2010           0         50        250
         6 19.04.2010          50          0        300
         7 21.04.2010           0         30        270
7 rows selected

Detaylar

Length Fonksiyonu

LENGTH (string) fonksiyonu paremetre olarak verilen string‘in karakter uzunluğunu döndürür.Parametre olarak verilen değer null ise dönen değerde null olur. string ” (boş string) ise null olarak işlem görür. Uzunluk değeri Sıfır (0) olarak dönmez.

SQL> select Length('Zeki Güven') from dual;
LENGTH('ZEKIGüVEN')
-------------------
10
SQL> select Length(10) from dual;
LENGTH(10)
----------
2
SQL> select Length(sysdate) from dual;
LENGTH(SYSDATE)
---------------
10
SQL> select Length(null) from dual;
LENGTH(NULL)
------------
SQL> select Length('') from dual;
LENGTH('')
----------
SQL> Select nvl('','NULL ise çalışır') from dual;
NVL('','NULLISEÇALIŞIR')
--------------------------------
NULL ise çalışır
SQL> select Length('X') from dual;
LENGTH('X')
-----------
1”

veya Null değerinin uzunluğu sıfır değildir.


www.zekiguven.com 'a güzel yazısı için teşekkürler.

Detaylar

İki tarih arası farkı Yıl, Ay, Gün olarak bulmak

İki tarih arasında geçen zamanı bulmanız, yaş hesaplamanız gerekebilir. Oracle’da iki tarih
arasındaki farkı yıl, ay,gun olarak veren fonksiyon bulunmamaktadır.
Ben aşağıdaki şekilde bir sql ile hallettim:

SQL>SELECT
DOG_TAR DOGUM_TARIHI,
TRUNC( MONTHS_BETWEEN( SYSDATE, dog_tar)/12) yil,
TRUNC( MOD( MONTHS_BETWEEN( SYSDATE, dog_tar),12) ) ay,
TRUNC( (MONTHS_BETWEEN(SYSDATE,dog_tar)- TRUNC(MONTHS_BETWEEN( SYSDATE,
dog_tar))) /0.032258064516129) gun
FROM
PERSONEL;
DOGUM_TARIHI YIL AY GUN
------------ ---------- ---------- ----------
11.04.1970 39 9 24
01.01.1960 50 1 3
01.01.1998 12 1 3
04.08.1997 12 6 0
13.02.1982 27 11 22
0.032258064516129 iki gün arasındaki fark.
SQL>SELECT MONTHS_BETWEEN( SYSDATE,SYSDATE-1) FROM DUAL;
MONTHS_BETWEEN(SYSDATE,SYSDATE
------------------------------
0,032258064516129

Detaylar

ORA-12549 Çözümü Mevcut!

Merhabalar,

Çok sıklıkla gerçekleşmese de, kısmen büyük çaptaki veritabanların başına gelebilen bir hatadır ORA-12549 hatası.

Veritabanına bağlanmak istediğiniz zaman ise şu şekilde hatalar alabilirsiniz;

ORA-12549: TNS: operating system resource quota exceeded

TNS-12518: TNS:listener could not hand off client connection

Ve veritabanına bağlanmanız reddedilir. İlk bakışta sıradan bir Oracle hatası ya da TNS hatası gibi gözüksede aslında bu bir İşletim sistemi kernel parametresi hatasından kaynaklanmaktadır.

Unix tabanlı işletim sistemlerinde bildiğiniz üzere belirli bir dökümantasyona göre Oracle kurulumları gerçekleştirilir, gerçekleştirilmesi tavsiye edilir. Gerçekleştirilmediği durumlarda ise, bir takım eksikliklerle Oracle veritabanı kurulacaktır ve ileride bir zaman karşınıza hata çıkma ihtimali olacaktır. Bu tarz işletim sistemlerinde kernel parametreleri vardır ve bağlı olan kullanıcılar ile ilgili işletim sistemi bazında bilgiler ve tanımlamaları içerir. Bu tanımlamalar belirli sayılarla temsil edilebilir.

Kernel parametrelerinin arasında "maxuproc" isimli bir parametre vardır. Default olarak 256 olarak belirlenir. Bu parametre her bir kullanıcı için azami işlem sayısını belirler. Oracle işletim sisteminden işlem tüketmek istediği zaman bu sayı sürekli artar ve 256'ya dayandığı zaman sisteme bağlantı dahil, veritabanı girişleri de sonlanabilir. Oracle'ın kurulum dökümantasyonlarında bu kernel parametrelerinin tavsiye edilen sayılarını görebilmek mevcut.

Bu parametreyi değiştirebilmek için root kullanıcısı ile bağlanmak şart. root ile bağlandıktan sonra "sam" yazarak parametremizi ayarlayacağımız Unix programına giriyoruz. Ardından "k" tuşuna basarak kernel parametrelerinin ayarlanması işlemine başlıyoruz. "Tunables" başlığının altında bir dizi parametre göreceksiniz. Burada "maxuproc" parametresini görebilirsiniz. Ayarlama olaraksa "(nproc*9)/10" yazarsanız, toplam nproc (işlem sayısı) sayısının %90'ını alabilir kullanıcılar demiş olursunuz. Bu sayede Oracle kullanıcınız daha fazla işlem tüketebilecek ve işlem sınırlamasından dolayı veritabanınız geçici süre kullanım dışı kalmayacaktır.

Unix/Linux işletim sistemlerine kurulum yaparken eğer kernel parametrelerinin kontrolünü atlarsanız kurulum aşamasında sorunlarla karşılaşmayabilirsiniz ancak ileride oluşabilecek sorunları da kabul etmiş olursunuz. Proaktif bir veritabanı yöneticisi olmak istiyorsanız ve sonradan başınızın ağrımasını istemiyorsanız unix tabanlı işletim sistemlerine Oracle veritabanı kurulumu yaparken mutlaka, mutlaka kernel parametrelerini kontrol edin!

maxuproc ile ilgili olarak google'da bir takım kısa çözümler mevcut. Örneğin;

Action: Acquire more operating system resource, or perform a different function.

Çok kısa ve anlaşılmayan bir çözüm değil mi? Daha fazla işletim sistemi kaynağı ayırmak ya da başka bir fonksiyon uygulamak ne demektir? Yukarıda yazdıklarımın çok fazla özeti olarak düşünüyorum ve maxuproc'u değiştirin diyorum :)

İyi akşamlar,

Detaylar

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.

Detaylar

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,

Detaylar

ORA-07445 "CORE DUMP"

Merhaba,
Bir Oracle hata kodu olan ORA-07445 çok fazla karşılaşılmayan bir işletim sistemi hatasıdır ve Oracle'ın alert.log dosyasında yazdırılır.
Hatanın çıktısı aşağıdaki şekilde olabilir;
Errors in file /opt/oracle/product/10.2.0/db_1/admin/opttest/bdump/opttest_ora_28677.trc:
ORA-07445: exception encountered: core dump [$cold_evacpy()+1328] [SIGILL] [Register NAT consumption] [0x40000000038FBC40] [] []
Bildiğimiz üzere core dump'ın sağındaki argümanlar, Oracle destek mühendislerinin probleme daha hızlı ulaşabilmeleri içindir. Eğer sistemde yukarıdaki hata oluşmuş ise mutlaka ve mutlaka Oracle Metalink'te servis talebi açılması gerekmektedir. Oracle destek mühendisleri önermedikçe bu durumu düzeltmek için Oracle'ın internal parametrelerini değiştirmemelisiniz!
Bu hata bir çeşit exception olduğu için SR açmanız gerekmektedir. Genel bir hata değildir.

Detaylar

ORA-3136

Merhaba,

ORA-03136 hatasına alert.log dosyasında başlıktaki gibi görebilirsiniz.

WARNING: inbound connection timed out (ORA-3136)

Bu hatanın alınmasındaki sebep, veritabanına bağlanmak isteyen bir kullanıcının kendisine tanımlanmış olan sürede, firewall, bağlantı problemleri gibi sebeplerden ötürü bağlanamamış olması.

Çözüm için listener'da bir parametreyi değiştmemiz ve bir dosya içerisine parametre eklememiz gerekebilir.

vals1:/home/oracle#lsnrctl
LSNRCTL for HPUX: Version 10.2.0.4.0 - Production on 23-NOV-2009 11:38:17
Copyright (c) 1991, 2007, Oracle. All rights reserved.
Welcome to LSNRCTL, type "help" for information.

LSNRCTL> set help
The following operations are available after set An asterisk (*) denotes a modifier or extended command: password rawmode displaymode trc_file trc_directory trc_level log_file log_directory log_status current_listener inbound_connect_timeout startup_waittime save_config_on_stop dynamic_registration

LSNRCTL> show inbound_connect_timeout
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 60
The command completed successfully

LSNRCTL> set inbound_connect_timeout 0
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER parameter "inbound_connect_timeout" set to 0
The command completed successfully

inbound_connect_timeout'un ilk değeri 60 saniyedir. Bu değeri sıfır yaparsak limitsiz olacağını belirtmiş oluyoruz.

Ardından $ORACLE_HOME/network/admin dizini içerisinde bulunan sqlnet.ora dosyasının içerisine aşağıdaki satırı ekliyoruz;

SQLNET.INBOUND_CONNECT_TIMEOUT 0

Bu işlemleri tamamladıktan sonra, bir süre daha alert.log günlük dosyasını incelemeye devam edin, problemin ortadan kalktığını göreceksiniz.

İyi çalışmalar,

Detaylar

ORA-00600 Hatası

Bir 600 hatası aldığınız zaman ilk ve mutlaka yapmanız gereken çözüm, metalink'i kontrol etmektir. Üzerinizdeki baskı gittikçe artacağı için google'a hiç bulaşmamanızı tavsiye ederim. Sıradan bir hata olmadığı için google size cevap veremeyecektir. Dolayısıyla önce metalink, eğer çözüm bulamadıysanız mecbur ticket açacaksınız ve Oracle'dan cevap bekleyeceksiniz YA DA veritabanının yedeğinden dönmeye razı olacaksınız :)

Geçtiğimiz günlerde ben de bir ORA-00600 hatası ile uğraştım ve gerçekten zor anlar yaşadım. Asıl beni germiş olan durum ise, test veritabanında olduğumuz ve ne yazık ki veritabanının hiçbir yedeğinin veya dump'ının olmaması. Hatta ve hatta veritabanı archivelog'da bile değildi :) Nasıl diyelim, kötü ve mutlak mağlubiyetle sonlanacak bir futbol maçı gibi. Sonradan yer sağlandı ve veritabanının archivelog'a geçirip, RMAN ile yedeğini alır hale geldik neyse ki.

Konumuza dönersek eğer, aldığım hata şöyleydi;

ORA-00600: internal error code, arguments: [kksfbc-reparse-infinite-loop],[ ],[ ],[ ],[ ],[ ]

Burada dikkat etmeniz gereken ilk şey, gelen ilk argümandır. Bu argüman, aslında hatanın nerede olduğunu ve doğal olarakta nasıl çözüleceğini anlatmaktadır. Sonrasında gelen argümanlar ise, problemi daha da detaylandırmakta kullanılmaktadır.

kksfbc-reparse-infinite-loop argümanı ile ne zaman karşılaşırsınız? Bu argüman çıktığı zaman ne yapmalısınız? Ben size burada yazacağım ve metalink ile uğraşma zahmetinden kurtaracağım.

Bu hatayı aldığınız zaman başınıza gelen şey aslında şudur; Veritabanındaki önemli şemalarda, örneğin SYS, SYSTEM, DBSNMP gibi INVALID objeler, yani hatalı, bozuk veya çalışmayan objeler olduğu anlamına gelmektedir. Paniğe gerek yok, bunu toparlamak için Oracle bize bir sql vermiştir ve bu sql damarlarındaki asil kanda mevcuttur :) $ORACLE_HOME/rdbms/admin folder'ının altında UTLRP.SQL isimli bir script bulunmaktadır. Bu script veritabanınızdaki bütün invalid objeleri valid hale getirmeye yaramaktadır. Şu şekilde çalıştırabilirsiniz;

@$ORACLE_HOME/rdbms/admin/utlrp.sql

Çalıştırdıktan sonra karşınıza 4 tane sql sorgusu ve neye yaradıklarını anlatan bir çıktı gelecektir. Başka bir terminal ile bağlanıp, bu sorguları takip edebilir ve scriptininiz ne kadar başarılı olduğunu görebilirsiniz. 2-3 defa çalıştırdığınız takdirde de hiçbir invalid obje kalmayacaktır. Yani bir defa çalıştırıp ohh kurtuldum diyerek rahatlamayın :)

Bu script'in en büyük ve tehlikeli impact'i kesinlikle şudur; sonuç olarak bu bir PL/SQL scripti'dir ve belirli paketler sayesinde çalışmaktadır. Eğer SYS şemanızdaki DBMS_UTILITY paketi invalid olduysa, bu scriptte çalışmayacaktır. Yine paniğe gerek yok, kurtarabilmenin bir yolu daha var. Ancak bu durumu düştüğünüzde kullanabilirsiniz.

$ORACLE_HOME/rdbms/admin folder'ının altında CATUPRGD.SQL isimli bir script var ve bu script yeni bir sürüm için katalog yükseltmesi yapmaktadır. Oracle tarafından internal olarak çağırılır. Kullanımı silent, yani responsefile ile grafik olmadan yapılan kurulumlardan sonra bir upgrade yapılmışsa, veritabanının kataloğunu da o sürüme yükseltmek içindir. Bu scripti çalıştırdıktan sonra sizden utlrp'yi çalıştırmanızı isteyecektir. Çünkü katalog yükseltmesi sırasında da invalid objeler oluşabilir.

Bütün bu yapılanlardan sonra hiçbir şemanızda invalid obje bulunmayacaktır ve veritabanını abort dışında bir yöntem ile kapatın ve temiz olarak açın. Probleminiz gitmiş olacaktır. Birgün boyunca alert_oraclesid.log dosyasını incelemeye (tail -f) devam ederseniz faydalı olacaktır.

Detaylar

Sql de ağaç yapısı ( CONNECT BY PRIOR )

Eğer tablomuz hiyerarşik bir veri yapısına (Örneğin Tree yapısı) sahip ise, verinizi hiyerarşisindeki sırasına göre getirmeniz mümkün. Aşağıdaki gibi bir veri yapımız oldugunu düşünelim.

İsterseniz SQL ifadeleri üzerinden gidelim ve sonuçlarını inceleyelim. Yukarıdaki yapıyı Oracle’ daki bir tabloda şu şekilde tutalım.
SQL 1 :
SELECT name, id, parent FROM test_table

Görüldüğü gibi veri yapımızı soyağacı yapımıza göre tasarladık…

SQL 2 :SELECT name, id, parent
FROM test_table
CONNECT BY PRIOR id = parent;

CONNECT BY PRIOR ile her veri satırına ait olası tüm ağaç ve alt ağaç yapılarını veren bir sonuç kümesi mevcut. Bu sonuç biraz karmaşık gelebilir. Bir başlangıç noktası belirtmek istersek;

SQL 3 :SELECT name, id, parent
FROM test_table
CONNECT BY PRIOR id = parent
START WITH parent = 0

START WITH ifadesi ile “0″ yani ağacımızın en tepesinde bulunan Büyükannemize ait alt kırılımları görüyoruz. Bu sonuç kümesini daraltmış olsada karmaşıklıgı ortadan kaldırmadıgını varsayalım ve verimizi biraz daha anlandırmak adına Oracle ın nimetlerinden faydalanalım;

SQL 4 :SELECT name, id, parent, SYS_CONNECT_BY_PATH(name, ‘ > ‘) AS yol
FROM test_table
CONNECT BY PRIOR id = parent
START WITH parent = 0;

Yol sütunumuzdan da anlaşılacagı gibi Ayşe büyükannemizin kendinden ufak olan aile fertlerini soyagacımız da ki yapıya uygun olacak şekilde anlamlaştırdık. Peki PRIOR ifadesinin yerini değiştirirsek ne olur ?

SQL 5 :SELECT name, id, parent, SYS_CONNECT_BY_PATH(name, ‘ > ‘) AS yol
FROM test_table
CONNECT BY id = PRIOR parent
START WITH parent = 0;

Demek ki PRIOR ifadesi CONNECT BY ile verilen şartta kendinden önceki ağaç seviyelerini baz alacagını bize veriyor. Burada da PARENT=0 diye bir başlangıç noktası verdiğimiz  ve PARENT alanını baz aldıgımız için kendi ve kendinden öncesini getirmiş oldu. Sql ifademizi biraz daha renklendirelim;

SQL 6 :SELECT name, id, parent, CONNECT_BY_ISLEAF AS yaprak, LEVEL AS seviye
FROM test_table t
START WITH parent = 0
CONNECT BY PRIOR id = parent

Bu son ifade de yeralan CONNECT_BY_ISLEAF ifadesi ile ilgili kaydın ağaç yapımızda ki son veri (Bir ağaçtaki son uzuv yaprak olmasından feyz alınarak) ise de “1″ değerini, kendine ait alt bir verisi varsa da “0″ degerini döndürür. Bir diğer ifade olan LEVEL ile de büyükannemize olan birim uzaklık değerini alıyoruz.

İyi Çalışmalar…

Detaylar

Oracle 10G ile Pivot Table

Oracle 11G ile PIVOT Fonksiyonu geldi. Ama ben yazımı 10G de bu işlemi SQL ile nasıl yapabileceğimizi göstericem. Veri setimiz;

SELECT * FROM test_data

Bizden istenilen PIVOT tablo;

• IL değerlerine ait
• GRUP değerleri bazında
• ADET değerlerinin toplamları

Sorgumuz;

SELECT il,
SUM(DECODE(grup,10,adet)) grup_10,
SUM(DECODE(grup,20,adet)) grup_20,
SUM(DECODE(grup,30,adet)) grup_30,
SUM(DECODE(grup,40,adet)) grup_40
FROM test_data
GROUP BY il
ORDER BY il

Sonuç çıktımız;

Detaylar

Oracle 'da Dinamik Sql Kodu Çalıştırma

Test tablomuzu oluşturalim;

CREATE TABLE test_table (kolon VARCHAR2 (100));

Sonra bu tablomuza bir kayıt girelim. Bunu basit bir SQL ifadesi ile değil de PL/SQL blokları içinde biraz parametrik yapmayı deneytelim;

DECLARE
v_sql VARCHAR2 (1000);
v_test_table VARCHAR2 (30) := ‘test_table’;
v_test_value VARCHAR2 (100) := ‘test value’;
BEGIN
v_sql := ‘INSERT INTO ‘ || v_test_table || ‘ values (:value)’;
EXECUTE IMMEDIATE v_sql USING v_test_value;
END;

Detaylar

Oracle Hata Kodları

Oracle ile ilgilenen herkes mutlaka bir hata ile karşılaşmıştır. Bu hata kodları bazen çok manalı olmayabiliyor, bu sebeple karşılaştığım bir link hoşuma gitti. İlgili hata kodunu yazarak hata kodunu/mesajını daha anlamlı hale getirmek isterseniz denemeye değer;

http://www.ora-error.com/

Detaylar