Ç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.
20 Kasım 2010 Cumartesi
27 Ekim 2010 Çarşamba
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
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
26 Ekim 2010 Salı
ORACLE-Shared server konfigurasyonu
Shared server özelliğini kullanabilmek için server(gerekli parametrelerin set edilmesi) ve client(tnsnames.ora) tarafında bazı ayarlar gerekli olabilir
Oracle 10g ve 11g versiyonlarında shared_servers ve dispatchers initialization
parametrelerinin set edilmesi ile server tarafında shared server
özelliği aktifleştirilmiş olur.
Bu parametreler database in restart edilmesine ihtiyaç duymayan parametrelerdendir.
Şu anki durumu görmek için aşağıdaki sorgu kullanılabilir.
select name,value from v$parameter
where name = 'shared_servers'
select name,value from v$parameter
where name = 'dispatchers'
shared_servers parametresi 1 den büyük bir değere set edilerek shared server
konfigurasyonu aktif edilmiş olur.
Shared server konfigurasyonunu aktif oracle instance ına uygulamak için
aşağıdaki komutları kullanabilirsiniz. Herhangibir değişiklik yapmadan önce eski
değerleri bir kenara yazmanızda her zaman fayda vardır.
alter system set shared_servers=5;
alter system set dispatchers='(PROTOCOL=TCP)';
Yapılan değişikli kısa bir süre sonra aktif olacaktır.
Bu değişiklikler aktif olduktan sonra, eğer bağlantı için
tns yöntemi kullanılıyorsa, tnsnames.ora dosyasındaki ayarlar bağlantının
shared veya dedicated olmasını belirler.
Mesela aşağıdaki gibi bir tnsnames.ora dosyası ile bağlantı yapılıyorsa
oluşan bağlantı shared olur.
bizim_db=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=bizim_host_veya_ip)
(PORT=1521)
)
(CONNECT_DATA=
(SERVER=shared)
(SID=bizim_db)
)
)
Benzer şekilde TNSNAMES.ORA dosyasındaki,
SERVER=dedicated şeklindeki kullanım bağlantının dedicated yapılması gerektiğini bildirecektir.
Easy connect veya connection string ile bağlanma durumunda
default olarak bağlantı shared olacaktır.
Kurulan bağlantının dedicated veya shared olduğunu tespit etmek için
v$session görünümü kullanılabilir.
select username,server from v$session order by server desc
Burada server sütünu SHARED ve NONE olan bağlantılar shared bağlantılardır.
alter system komutu ile yapılan değişiklikler kalıcı olsun istiyorsanız,
kullandığınız server parametre dosyasında gerekli değişiklikleri yapmalısınız.
Buradaki shared_servers parametresinin değerini duruma göre ayarlayabilirsiniz.
5 yerine 10 shared server ile de başlayabilirdik mesela.
Ayrıca max_shared_servers parametresini set ederek açılabilecek max server process
sayısını da set edebilirdik.
Daha fazla bilgi için aşağıdaki bağlantı incelenebilir.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc003.htm
Oracle 10g ve 11g versiyonlarında shared_servers ve dispatchers initialization
parametrelerinin set edilmesi ile server tarafında shared server
özelliği aktifleştirilmiş olur.
Bu parametreler database in restart edilmesine ihtiyaç duymayan parametrelerdendir.
Şu anki durumu görmek için aşağıdaki sorgu kullanılabilir.
select name,value from v$parameter
where name = 'shared_servers'
select name,value from v$parameter
where name = 'dispatchers'
shared_servers parametresi 1 den büyük bir değere set edilerek shared server
konfigurasyonu aktif edilmiş olur.
Shared server konfigurasyonunu aktif oracle instance ına uygulamak için
aşağıdaki komutları kullanabilirsiniz. Herhangibir değişiklik yapmadan önce eski
değerleri bir kenara yazmanızda her zaman fayda vardır.
alter system set shared_servers=5;
alter system set dispatchers='(PROTOCOL=TCP)';
Yapılan değişikli kısa bir süre sonra aktif olacaktır.
Bu değişiklikler aktif olduktan sonra, eğer bağlantı için
tns yöntemi kullanılıyorsa, tnsnames.ora dosyasındaki ayarlar bağlantının
shared veya dedicated olmasını belirler.
Mesela aşağıdaki gibi bir tnsnames.ora dosyası ile bağlantı yapılıyorsa
oluşan bağlantı shared olur.
bizim_db=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=bizim_host_veya_ip)
(PORT=1521)
)
(CONNECT_DATA=
(SERVER=shared)
(SID=bizim_db)
)
)
Benzer şekilde TNSNAMES.ORA dosyasındaki,
SERVER=dedicated şeklindeki kullanım bağlantının dedicated yapılması gerektiğini bildirecektir.
Easy connect veya connection string ile bağlanma durumunda
default olarak bağlantı shared olacaktır.
Kurulan bağlantının dedicated veya shared olduğunu tespit etmek için
v$session görünümü kullanılabilir.
select username,server from v$session order by server desc
Burada server sütünu SHARED ve NONE olan bağlantılar shared bağlantılardır.
alter system komutu ile yapılan değişiklikler kalıcı olsun istiyorsanız,
kullandığınız server parametre dosyasında gerekli değişiklikleri yapmalısınız.
Buradaki shared_servers parametresinin değerini duruma göre ayarlayabilirsiniz.
5 yerine 10 shared server ile de başlayabilirdik mesela.
Ayrıca max_shared_servers parametresini set ederek açılabilecek max server process
sayısını da set edebilirdik.
Daha fazla bilgi için aşağıdaki bağlantı incelenebilir.
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc003.htm
ORACLE-Shared server opsiyonu
Oracle database , kendisine gelen request(istek) leri cevaplamak için
server tarafında server process ler oluşturur. Bu oluşturulan process ler
bizim query(insert,update ..) lerimizi gerçekleştirirler.
Kullanıcı isteklerini karşılamak için Oracle ın kullandığı
server process lerinin iki türü vardır. Dedicated ve shared.
Kısaca; dedicated server process leri yalnız bir session a hizmet eder.
Yani her farklı session için ayrı bir dedicated server process i tahsis edilir.
Shared server process leri birden çok session a hizmet eder.
Yani her farklı session için ayrı bir shared server process i tahsis edilmez.
Başlangıçtaki shared server sayısı ve max shared server sayısı
tanımlanabilir.
Pek çok kaynakta dedicated ve shared server process leri arası farkı
açıklamak için lokanta-garson ilişkisi kullanılıyor.
Ben de burada aynı örneği vereceğim.
Diyelim ki bir lokantaya gittiniz. Bu lokantada, bir garson size tahsis edilmiş durumda ve bu garson başka hiçbir işle uğraşmadan sizin ihtiyaçlarınızla ilgileniyor.
İşte dedicated server bağlantısıda aynen bu şekilde çalışıyor.
Bu lokantadaki 3 garson sizin ve diğer müşterilerin ihtiyaçları ile
ilgileniyor olursa, bu durumda shared server connection larının çalışma
şeklini örneklemekte.
Anlattıklarımızı gerçek dünyaya ölçeklendirelim.
Diyelimki database imize bağlanan ortalama 200 user session ı oluyor.
Bu durumda shared server mimarisini kullanarak, bu 200 user session ı
10 ile 30 arası shared server process i kullansın diyebiliriz.
Ne zaman tercih edilmeli ?
----------------------------
* Eğer connection sayınız 100 üzeri ise,
* 32 bit server kullanıyorsanız,
* Uygulama web uygulaması ise,
* Oracle, yeterince güçlü bir donanım üzerinde çalıştırılmıyorsa,
bu opsiyon değerlendirilebilir diye düşünüyorum.
Eğer zaman zaman veya devamlı olarak, yeni connection açarken
oracle hatası alıyor ve connection açamıyorsanız sorun
yeni dedicated process oluşturmak için yeterli boş bellek bulunmaması olabilir.
Bu durumdaysanız, ya acilen server
belleğini arttırmalı(64 bit işletim sistemi kullanmıyorsanız işe yaramayabilir)
yada shared server konfigurasyonu yapmalısınız.
Acılan her dedicated server process i için memory ve
kaynak tahsis edilir. Shared server bağlantıarı kullanılan durumda
gerekli kaynak ihtiyacı da düşmektedir.
Shared database connection larının en iyi kullanım şekli,
database e bağlı kalan fakat çoğu zaman aktif olarak iş yapmayan kullanıcılar
için kullanılmalarıdır.
Dedicated ve shared server bağlantıları bir arada kullanılabilir.
Yani mesela, database e giriş yapan bir kullanıcı grubu
shared connection kullanırken, raporlama yapan bir başka kullanıcı grubu
dedicated connection kullanabilir.
Daha fazla bilgi için aşağıdaki bağlantılara gözatabilirsiniz.
http://www.dba-oracle.com/t_mts_multithreaded_servers_shared.htm
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc001.htm
server tarafında server process ler oluşturur. Bu oluşturulan process ler
bizim query(insert,update ..) lerimizi gerçekleştirirler.
Kullanıcı isteklerini karşılamak için Oracle ın kullandığı
server process lerinin iki türü vardır. Dedicated ve shared.
Kısaca; dedicated server process leri yalnız bir session a hizmet eder.
Yani her farklı session için ayrı bir dedicated server process i tahsis edilir.
Shared server process leri birden çok session a hizmet eder.
Yani her farklı session için ayrı bir shared server process i tahsis edilmez.
Başlangıçtaki shared server sayısı ve max shared server sayısı
tanımlanabilir.
Pek çok kaynakta dedicated ve shared server process leri arası farkı
açıklamak için lokanta-garson ilişkisi kullanılıyor.
Ben de burada aynı örneği vereceğim.
Diyelim ki bir lokantaya gittiniz. Bu lokantada, bir garson size tahsis edilmiş durumda ve bu garson başka hiçbir işle uğraşmadan sizin ihtiyaçlarınızla ilgileniyor.
İşte dedicated server bağlantısıda aynen bu şekilde çalışıyor.
Bu lokantadaki 3 garson sizin ve diğer müşterilerin ihtiyaçları ile
ilgileniyor olursa, bu durumda shared server connection larının çalışma
şeklini örneklemekte.
Anlattıklarımızı gerçek dünyaya ölçeklendirelim.
Diyelimki database imize bağlanan ortalama 200 user session ı oluyor.
Bu durumda shared server mimarisini kullanarak, bu 200 user session ı
10 ile 30 arası shared server process i kullansın diyebiliriz.
Ne zaman tercih edilmeli ?
----------------------------
* Eğer connection sayınız 100 üzeri ise,
* 32 bit server kullanıyorsanız,
* Uygulama web uygulaması ise,
* Oracle, yeterince güçlü bir donanım üzerinde çalıştırılmıyorsa,
bu opsiyon değerlendirilebilir diye düşünüyorum.
Eğer zaman zaman veya devamlı olarak, yeni connection açarken
oracle hatası alıyor ve connection açamıyorsanız sorun
yeni dedicated process oluşturmak için yeterli boş bellek bulunmaması olabilir.
Bu durumdaysanız, ya acilen server
belleğini arttırmalı(64 bit işletim sistemi kullanmıyorsanız işe yaramayabilir)
yada shared server konfigurasyonu yapmalısınız.
Acılan her dedicated server process i için memory ve
kaynak tahsis edilir. Shared server bağlantıarı kullanılan durumda
gerekli kaynak ihtiyacı da düşmektedir.
Shared database connection larının en iyi kullanım şekli,
database e bağlı kalan fakat çoğu zaman aktif olarak iş yapmayan kullanıcılar
için kullanılmalarıdır.
Dedicated ve shared server bağlantıları bir arada kullanılabilir.
Yani mesela, database e giriş yapan bir kullanıcı grubu
shared connection kullanırken, raporlama yapan bir başka kullanıcı grubu
dedicated connection kullanabilir.
Daha fazla bilgi için aşağıdaki bağlantılara gözatabilirsiniz.
http://www.dba-oracle.com/t_mts_multithreaded_servers_shared.htm
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/manproc001.htm
20 Ekim 2010 Çarşamba
MySQL - Too Many Connections error
"Too Many Connections" hatası çeşitli nedenlerle oluşabilir;
* Aynı anda çok sayıda connection oluşturulması
* Eski connection ların yeteri kadar hızlı serbest bırakılamaması
* Eski konnection ların bir nedenle kapatılmaması
MySQL ayarlarında ve application kodlarında çeşitli
değişiklikler yapılarak bu hata düzeltilir.
KOD SEVİYESİNDE YAPILABİLECEKLER
-----------------------------------------
* Eğer kalıcı bir connection dan bahsetmiyorsak, açılan connection un kapatılmasının
garanti altına alınmış olmalıdır. Aksi taktirde, mesela bir exception sonucu açılan connection nun
close edilmemesi, gibi bir nedenle Too Many Connections error alınabilir. Yada açılan connection un kapatılması unutulmuş olabilir.
* Uzun zaman alan query lerin tune edilmesi
MYSQL SERVER AYARLARI İLE İLGİLİ YAPILABİLECEKLER
---------------------------------------------------
* max_connections parametresinin arttırılması
Açılabilecek max. connection sayısı "max_connections" global değişkeni ile kontrol edilir.
MySQL 5.1.15 ve sonrasında bu değişkenin default değeri 151 gelmektedir.
mysql, max_connectionsparametresi değerinin 1 fazlası kadar bağlantıya izin verir.
Bu bir fazla kısma sadece SUPER yetkisine sahip kullanıcı bağlanabilir.
Bu nedenle de applicationda kullanılan user ın SUPER yetkisine sahip bir user olmaması
önemlidir.
Şu andaki aktif bağlantılar SHOW PROCESSLIST komutu ile görüntülenebilir.
max_connections parametresinin değeri arttırırken dikkatli olmak gereklidir.
Çünkü sonuçta her yeni connection bir miktar sistem kaynağı kullanır.
* max_user_connections parametresinin set edilmesi
Herhangibir user için veya genel olarak bir user ın
açabileceği maximum connection sayısı set edilmelidir.
Default olarak her kullanıcı sınırsız sayıda session açabilir.
* wait_timeout ve interactive_timeout parametrelerinin set edilmesi
Bu parametreler set edilerek, belli bir süre iş yapmayan sessionlar
otomatik olarak sonlandırılabilir.
Default olarak wait_timeout ve interactive_timeout
değişkenlerinin değeri 8 saattir.
Yani mysql e bağlanan kullanıcı hiçbir iş yapmazsa
8 saat sonra connection otomatik kapatılır.
Daha fazla bilgi için aşağıdaki bağlantılar faydalı olacaktır.
http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_wait_timeout
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_interactive_timeout
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_user_connections
* Aynı anda çok sayıda connection oluşturulması
* Eski connection ların yeteri kadar hızlı serbest bırakılamaması
* Eski konnection ların bir nedenle kapatılmaması
MySQL ayarlarında ve application kodlarında çeşitli
değişiklikler yapılarak bu hata düzeltilir.
KOD SEVİYESİNDE YAPILABİLECEKLER
-----------------------------------------
* Eğer kalıcı bir connection dan bahsetmiyorsak, açılan connection un kapatılmasının
garanti altına alınmış olmalıdır. Aksi taktirde, mesela bir exception sonucu açılan connection nun
close edilmemesi, gibi bir nedenle Too Many Connections error alınabilir. Yada açılan connection un kapatılması unutulmuş olabilir.
* Uzun zaman alan query lerin tune edilmesi
MYSQL SERVER AYARLARI İLE İLGİLİ YAPILABİLECEKLER
---------------------------------------------------
* max_connections parametresinin arttırılması
Açılabilecek max. connection sayısı "max_connections" global değişkeni ile kontrol edilir.
MySQL 5.1.15 ve sonrasında bu değişkenin default değeri 151 gelmektedir.
mysql, max_connectionsparametresi değerinin 1 fazlası kadar bağlantıya izin verir.
Bu bir fazla kısma sadece SUPER yetkisine sahip kullanıcı bağlanabilir.
Bu nedenle de applicationda kullanılan user ın SUPER yetkisine sahip bir user olmaması
önemlidir.
Şu andaki aktif bağlantılar SHOW PROCESSLIST komutu ile görüntülenebilir.
max_connections parametresinin değeri arttırırken dikkatli olmak gereklidir.
Çünkü sonuçta her yeni connection bir miktar sistem kaynağı kullanır.
* max_user_connections parametresinin set edilmesi
Herhangibir user için veya genel olarak bir user ın
açabileceği maximum connection sayısı set edilmelidir.
Default olarak her kullanıcı sınırsız sayıda session açabilir.
* wait_timeout ve interactive_timeout parametrelerinin set edilmesi
Bu parametreler set edilerek, belli bir süre iş yapmayan sessionlar
otomatik olarak sonlandırılabilir.
Default olarak wait_timeout ve interactive_timeout
değişkenlerinin değeri 8 saattir.
Yani mysql e bağlanan kullanıcı hiçbir iş yapmazsa
8 saat sonra connection otomatik kapatılır.
Daha fazla bilgi için aşağıdaki bağlantılar faydalı olacaktır.
http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_wait_timeout
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_interactive_timeout
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_user_connections
19 Ekim 2010 Salı
Netbeans - wsimport karakter sorunu
Netbeans te hazırladığım projede, webservis import aşamasından sonra
oluşan kaynak kodlarda , netbeans tarafından generate edilen ve kodu
bozan ek java kodları oluşmaya başladı.
Farkettim ki bu sorun windows işletim sisteminin
regional settings i ile ilgili imiş.
Windows Regional Settings - Format alanını US yapınca sorun çözüldü.
oluşan kaynak kodlarda , netbeans tarafından generate edilen ve kodu
bozan ek java kodları oluşmaya başladı.
Farkettim ki bu sorun windows işletim sisteminin
regional settings i ile ilgili imiş.
Windows Regional Settings - Format alanını US yapınca sorun çözüldü.
1 Ekim 2010 Cuma
Adım adım MySQL Replication
Başlangıç olarak master ve slave tarafında MySQL server in kurulu olduğunu,
her iki server için gerekli network ayarlarının yapıldığını varsayıyorum.
Öncelik replikasyon için gerekli olan bazı MySQL server konfigurasyon
ayarlarının her iki taraf için de kontrol edilmesi gerekiyor.
Bu ayarlar işletim sisteminize bağlı olarak my.cnf veya my.ini
dosyası içerisinde bulunabilir. Ben burada işletim sisteminin
linux olduğunu varsayarak devam edeceğim.
1-Master veritabanında slave için user oluşturulması
Master da çalıştırılacak;
mysql> GRANT REPLICATION SLAVE ON *.* TO `slaveuser`@`slave_ip` IDENTIFIED BY '1234';
2-MySQL parametrelerinin ayarlanması
Master için;
[mysqld]
server_id=10
log_bin = mysql-bin
Slave için;
[mysqld]
server_id=20
log_bin = mysql-bin
relay_log = mysql-relay-bin
log_slave_updates = 1
read_only = 1
Burada "server_id" , her database server e farklı atamanız gereken bir tamsayıdır.
Ben bu server_id nin IP adresi ile ilişkilendirerek kullanıyorum.
Mesela, server IP adresi 192.168.2.10 için kullanacağımız server_id de 10 olacak.
3-Master ve slave veritabanlarının kapatılması
Yukarıdaki değişiklikleri yaptıktan sonra server larımızın kapatılıp açılması gerekiyor. Böylece değişikliklerimiz aktif olacak. Şimdi her iki
veritabanını da kapatıyoruz.
Master ve slave de çalıştırılacak;
-bash-3.2$ /etc/init.d/mysql stop
Bu aşamada MySQL server larımızın konfigurasyon dosyaları replikasyona hazır durumda.
4-Master veritabanının slave e kopyalanması
Önce slave veritabanınızın data klasörünü tamamen silin.
Burada my.cnf veya my.ini konfigurasyon dosyası data klasöründeyse bu dosyayı değiştirmemeye/silmemeye dikkat etmeniz yeterli.
Master veritabanına ait data klasörünü slave veritabanımızın data klasörüne kopyalayın. Böylece her iki veri tabanımız eşitlenmiş olacak. (Kopyalama sırasında master hemde slave veritabanları
kapalı olmalı.)
Böylece slave veritabanımızın, master ile aynı olmasını sağlamış olduk.
5-Master ve slave veri tabanlarının açılması
Master ve slave de çalıştırılır;
-bash-3.2$ /etc/init.d/mysql start
6-Slave veritabanının master a bağlanması için gerekli parametrelerin set edilmesi
Aşağıdaki komutu çalıştırarak slave veritabanının master veritabanına
replikasyon için bağlantı parametreleri set edilir.
mysql> CHANGE MASTER TO
MASTER_HOST='ServerIP/FQDN',
MASTER_USER='ReplClient',
MASTER_PASSWORD='ClientPassword';
7-Replikasyonun başlatılması ve kontrol edilmesi
Slave tarafında start slave komutu çalıştırılarak replikasyon başlatılır.
mysql> START SLAVE;
Slave tarafında SHOW SLAVE STATUS komutu ile replikasyon durumu görüntülenir.
Gelen ekranda herhangibir error olmamalıdır.
mysql> SHOW SLAVE STATUS\G
NOTLAR
***************************************
Replikasyonu başlatabilmek için, slave veritabanına , master daki hangi
noktadan değişiklikleri uygulamaya başlayacağını bildirmek gerekiyor.
Bu nedenle master veritabanını kapatmadan slave veritabanı konfigure etmek
ek adımlar ile mümkün. Biz burada master varitabanını kapatıp kopyalarak
her iki veri tabanını eşitleme adımını başarmış olduk.
Eğer başarı ile replikasyonu tamamlayabildiysek,
bundan sonra master a uygulanan ve veritabanında değişiklik yaratan
her query, slave e uygulandığından, slave deki verimiz master dakine
maximum eşitlikte olacaktır. Burada maximum eşitlikte diyorum çünkü
örneğin insert deyimi içinde now() fonksiyonu kullanırsanız
slave tarafındaki veri, master tarafından farklı olabilecektir.
(Statement Based Replication)
Daha fazla bilgi için aşağıdaki linki inceleyebilirsiniz.
http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html
Daha fazla bilgi için;
http://dev.mysql.com/doc/refman/5.1/en/replication-howto.html
her iki server için gerekli network ayarlarının yapıldığını varsayıyorum.
Öncelik replikasyon için gerekli olan bazı MySQL server konfigurasyon
ayarlarının her iki taraf için de kontrol edilmesi gerekiyor.
Bu ayarlar işletim sisteminize bağlı olarak my.cnf veya my.ini
dosyası içerisinde bulunabilir. Ben burada işletim sisteminin
linux olduğunu varsayarak devam edeceğim.
1-Master veritabanında slave için user oluşturulması
Master da çalıştırılacak;
mysql> GRANT REPLICATION SLAVE ON *.* TO `slaveuser`@`slave_ip` IDENTIFIED BY '1234';
2-MySQL parametrelerinin ayarlanması
Master için;
[mysqld]
server_id=10
log_bin = mysql-bin
Slave için;
[mysqld]
server_id=20
log_bin = mysql-bin
relay_log = mysql-relay-bin
log_slave_updates = 1
read_only = 1
Burada "server_id" , her database server e farklı atamanız gereken bir tamsayıdır.
Ben bu server_id nin IP adresi ile ilişkilendirerek kullanıyorum.
Mesela, server IP adresi 192.168.2.10 için kullanacağımız server_id de 10 olacak.
3-Master ve slave veritabanlarının kapatılması
Yukarıdaki değişiklikleri yaptıktan sonra server larımızın kapatılıp açılması gerekiyor. Böylece değişikliklerimiz aktif olacak. Şimdi her iki
veritabanını da kapatıyoruz.
Master ve slave de çalıştırılacak;
-bash-3.2$ /etc/init.d/mysql stop
Bu aşamada MySQL server larımızın konfigurasyon dosyaları replikasyona hazır durumda.
4-Master veritabanının slave e kopyalanması
Önce slave veritabanınızın data klasörünü tamamen silin.
Burada my.cnf veya my.ini konfigurasyon dosyası data klasöründeyse bu dosyayı değiştirmemeye/silmemeye dikkat etmeniz yeterli.
Master veritabanına ait data klasörünü slave veritabanımızın data klasörüne kopyalayın. Böylece her iki veri tabanımız eşitlenmiş olacak. (Kopyalama sırasında master hemde slave veritabanları
kapalı olmalı.)
Böylece slave veritabanımızın, master ile aynı olmasını sağlamış olduk.
5-Master ve slave veri tabanlarının açılması
Master ve slave de çalıştırılır;
-bash-3.2$ /etc/init.d/mysql start
6-Slave veritabanının master a bağlanması için gerekli parametrelerin set edilmesi
Aşağıdaki komutu çalıştırarak slave veritabanının master veritabanına
replikasyon için bağlantı parametreleri set edilir.
mysql> CHANGE MASTER TO
MASTER_HOST='ServerIP/FQDN',
MASTER_USER='ReplClient',
MASTER_PASSWORD='ClientPassword';
7-Replikasyonun başlatılması ve kontrol edilmesi
Slave tarafında start slave komutu çalıştırılarak replikasyon başlatılır.
mysql> START SLAVE;
Slave tarafında SHOW SLAVE STATUS komutu ile replikasyon durumu görüntülenir.
Gelen ekranda herhangibir error olmamalıdır.
mysql> SHOW SLAVE STATUS\G
NOTLAR
***************************************
Replikasyonu başlatabilmek için, slave veritabanına , master daki hangi
noktadan değişiklikleri uygulamaya başlayacağını bildirmek gerekiyor.
Bu nedenle master veritabanını kapatmadan slave veritabanı konfigure etmek
ek adımlar ile mümkün. Biz burada master varitabanını kapatıp kopyalarak
her iki veri tabanını eşitleme adımını başarmış olduk.
Eğer başarı ile replikasyonu tamamlayabildiysek,
bundan sonra master a uygulanan ve veritabanında değişiklik yaratan
her query, slave e uygulandığından, slave deki verimiz master dakine
maximum eşitlikte olacaktır. Burada maximum eşitlikte diyorum çünkü
örneğin insert deyimi içinde now() fonksiyonu kullanırsanız
slave tarafındaki veri, master tarafından farklı olabilecektir.
(Statement Based Replication)
Daha fazla bilgi için aşağıdaki linki inceleyebilirsiniz.
http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html
Daha fazla bilgi için;
http://dev.mysql.com/doc/refman/5.1/en/replication-howto.html
29 Eylül 2010 Çarşamba
MySQL Replication Hakkında
Replikasyon, eş zamanlıya en yakın backup çözümüdür. Ayrıca okuma isteklerinin ana server dışı serverlere de
yayılması ile ana server in yükünün hafifletilmesi anlamında iyi bir seçenek olabilmektedir.
MySQL, version 5.1 itibariyle iki tür replikasyonu desteklemektedir.
Bunlar statement-based ve row-based replikasyondur.
Statement-based (veya “logical”) replikasyon MySQL 3.23 den beri bulunmaktadır ve
bugünkü çoğu production sisteminde kullanılan replikasyon tipidir.
Row-based replikasyon MySQL 5.1 ile gelen bir özelliktir.
Her iki replikasyon tipi de temelde aynı mantıkla çalışır.
Database üzerinde yapılan değişiklikler master (replike edilecek database)
a ait binary log dosyasına yazılır. Ardında bu değişiklik (event)
slave (kopya database) e uygulanır.
Statement based replication, masterda çalıştırılan ve databasete değişiklik yaratan
query lerin slave de aynen uygulanmasıdır.
Row based replication da ise, değişen data blokları slave e uygulanır.
Bugünlerde Row based replikasyon çok yeni olduğundan dolayı henüz pek yaygın kullanılmıyor.
Fakat gelecekte en az statement based replikasyon kadar yaygınlaşacağını düşünüyorum.
MySQL Replikasyon düşük versiyondan yüksek versiyona doğru genellikle sorunsuz çalışıken
tersi he zaman sorun anlamına gelir.
Tavsiyem master ve slave mysql versiyonlarının aynı olmasıdır.
Replikasyon master sistem üzerinde genellikle çok az yük oluşturur.
Tabi çok sayıda slave olması bu durumu değiştirebilir.
yayılması ile ana server in yükünün hafifletilmesi anlamında iyi bir seçenek olabilmektedir.
MySQL, version 5.1 itibariyle iki tür replikasyonu desteklemektedir.
Bunlar statement-based ve row-based replikasyondur.
Statement-based (veya “logical”) replikasyon MySQL 3.23 den beri bulunmaktadır ve
bugünkü çoğu production sisteminde kullanılan replikasyon tipidir.
Row-based replikasyon MySQL 5.1 ile gelen bir özelliktir.
Her iki replikasyon tipi de temelde aynı mantıkla çalışır.
Database üzerinde yapılan değişiklikler master (replike edilecek database)
a ait binary log dosyasına yazılır. Ardında bu değişiklik (event)
slave (kopya database) e uygulanır.
Statement based replication, masterda çalıştırılan ve databasete değişiklik yaratan
query lerin slave de aynen uygulanmasıdır.
Row based replication da ise, değişen data blokları slave e uygulanır.
Bugünlerde Row based replikasyon çok yeni olduğundan dolayı henüz pek yaygın kullanılmıyor.
Fakat gelecekte en az statement based replikasyon kadar yaygınlaşacağını düşünüyorum.
MySQL Replikasyon düşük versiyondan yüksek versiyona doğru genellikle sorunsuz çalışıken
tersi he zaman sorun anlamına gelir.
Tavsiyem master ve slave mysql versiyonlarının aynı olmasıdır.
Replikasyon master sistem üzerinde genellikle çok az yük oluşturur.
Tabi çok sayıda slave olması bu durumu değiştirebilir.
8 Eylül 2010 Çarşamba
Mysql database kapatma - açma (Linux)
MySQL server şu anki durumu
******************************
/etc/init.d/mysql status
MySQL server başlatma
******************************
/etc/init.d/mysql start
MySQL server durdurma
******************************
/etc/init.d/mysql stop
Bu işlemler root veya mysql kullanıcı ile gerçekleştirilebilir.
******************************
/etc/init.d/mysql status
MySQL server başlatma
******************************
/etc/init.d/mysql start
MySQL server durdurma
******************************
/etc/init.d/mysql stop
Bu işlemler root veya mysql kullanıcı ile gerçekleştirilebilir.
Oracle Enterprise Linux 5 üzerine MySQL Server 5.1 kurulumu
Mysql dökümantasyonunda belirtildiği gibi mysql linux üzerinde geliştirilmektedir.
Bu nedenle de linux, mysql kurulumu için en uygun ortam olmaktadır.
Burada kurulumu özellikle Oracle Enterprise Linux 5 üzerinde gerçekleştiriyorsakta
diğer linux dağıtımları için de prosedür aynıdır.
32 bir işletim sistemleri her proses için en çok 2.4 Gb memory ayırabilmektedir.
Bu nedenle pek çok kurulumda 64 bit işletim sistemi tercih edilmektedir.
Bizde burada 64 OEL dağıtımı üzerine MySQL server kurulumu tamamlıyor olacağız.
Linux üzerindeki MySQL server kurulumu için server ve client rpm paketlerinin kurulumu yeterlidir.
Kurulum aşağıdaki adımlardan oluşur.
* Gerekli RPM paketlerini bilgisayarımıza indiriyoruz.
1. http://dev.mysql.com/downloads/mysql/#downloads adresine gidiyoruz
2. Burada kurulumunu yapacağımız "Red Hat & Oracle Enterprise Linux" seçeneğini seçiyoruz.
3. 64 server ve client rpm ini indiriyoruz.
Bu kurulumda OEL üzerine şu an güncel olan MySQL 5.1.50 64 bit sürümünü kuruyoruz.
Download ettiğim dosyalar aşağıdaki gibidir.
MySQL-client-community-5.1.50-1.rhel5.x86_64.rpm
MySQL-server-community-5.1.50-1.rhel5.x86_64.rpm
* Yukarıdaki rpm dosyalarını, MySQL server kurmak istediğimiz sunucunun "tmp" klasörüne kopyalıyoruz.
* Bu aşamadan sonra sırasıyla server ve client rpm inin kurulumunu tamamlıyacağız.
Kurulum root user ı ile yapılmalıdır. Ayrıca linux işletim sisteminde küçük büyük harf ayrımı olduğu unutulmamalıdır.
Server kurulumu ile başlıyoruz.
[root@deneme tmp]# rpm -i MySQL-server-community-5.1.50-1.rhel5.x86_64.rpm
Bu komut çalıştırıldığında bir dizi olay arka planda gerçekleşmiştir.
1. Linux üzerinde mysql kullanıcı hesabı ve mysql grup hesabı oluşturulur.
2. MySQL dosyaları RPM paketinden çıkartılarak uygun klasörlere kopyalanır.
3. MySQL yönetimsel database ilk kullanıma hazırlanır.
4. MySQL ile alakalı klasörlerin sahiplik durumu düzenlenir.
5. MySQL server başlatılır.
6 MySQL server , her Linux restart ında otomatik çalışacak şekilde konfigure edilir.
Server kurulumunun tamamlanmasının ardından client kurulumuna geçilebilir.
[root@deneme tmp]# rpm -i MySQL-client-community-5.1.50-1.rhel5.x86_64.rpm
Bu noktada MySQL server kurulumu tamamlanmıştır.
Bu nedenle de linux, mysql kurulumu için en uygun ortam olmaktadır.
Burada kurulumu özellikle Oracle Enterprise Linux 5 üzerinde gerçekleştiriyorsakta
diğer linux dağıtımları için de prosedür aynıdır.
32 bir işletim sistemleri her proses için en çok 2.4 Gb memory ayırabilmektedir.
Bu nedenle pek çok kurulumda 64 bit işletim sistemi tercih edilmektedir.
Bizde burada 64 OEL dağıtımı üzerine MySQL server kurulumu tamamlıyor olacağız.
Linux üzerindeki MySQL server kurulumu için server ve client rpm paketlerinin kurulumu yeterlidir.
Kurulum aşağıdaki adımlardan oluşur.
* Gerekli RPM paketlerini bilgisayarımıza indiriyoruz.
1. http://dev.mysql.com/downloads/mysql/#downloads adresine gidiyoruz
2. Burada kurulumunu yapacağımız "Red Hat & Oracle Enterprise Linux" seçeneğini seçiyoruz.
3. 64 server ve client rpm ini indiriyoruz.
Bu kurulumda OEL üzerine şu an güncel olan MySQL 5.1.50 64 bit sürümünü kuruyoruz.
Download ettiğim dosyalar aşağıdaki gibidir.
MySQL-client-community-5.1.50-1.rhel5.x86_64.rpm
MySQL-server-community-5.1.50-1.rhel5.x86_64.rpm
* Yukarıdaki rpm dosyalarını, MySQL server kurmak istediğimiz sunucunun "tmp" klasörüne kopyalıyoruz.
* Bu aşamadan sonra sırasıyla server ve client rpm inin kurulumunu tamamlıyacağız.
Kurulum root user ı ile yapılmalıdır. Ayrıca linux işletim sisteminde küçük büyük harf ayrımı olduğu unutulmamalıdır.
Server kurulumu ile başlıyoruz.
[root@deneme tmp]# rpm -i MySQL-server-community-5.1.50-1.rhel5.x86_64.rpm
Bu komut çalıştırıldığında bir dizi olay arka planda gerçekleşmiştir.
1. Linux üzerinde mysql kullanıcı hesabı ve mysql grup hesabı oluşturulur.
2. MySQL dosyaları RPM paketinden çıkartılarak uygun klasörlere kopyalanır.
3. MySQL yönetimsel database ilk kullanıma hazırlanır.
4. MySQL ile alakalı klasörlerin sahiplik durumu düzenlenir.
5. MySQL server başlatılır.
6 MySQL server , her Linux restart ında otomatik çalışacak şekilde konfigure edilir.
Server kurulumunun tamamlanmasının ardından client kurulumuna geçilebilir.
[root@deneme tmp]# rpm -i MySQL-client-community-5.1.50-1.rhel5.x86_64.rpm
Bu noktada MySQL server kurulumu tamamlanmıştır.
17 Haziran 2010 Perşembe
ORACLE - SCN Nedir ? Ne işe yarar?
Sytem Change Number (SCN) sıralı bir biçimde artan, unique(benzersiz),
oracle database içerisinde tam olarak bir zamanı ifade eden, adı üstünde bir rakamdır.
Her transaction ın commit edilmesi ile beraber Oracle tarafından yeni bir SCN üretilir.
Oracle içerisinde, SCN isimli sıralı numaralar control file, datafile header ve redo kayıtlarında kullanır.
Her redo log dosyası bir log sequence numarası and low ve high SCN değerini içerir.
Low SCN kaydı ; log file içerisindeki en küçük SCN rakamını içerir.
High SCN kaydı ; log file içerisindeki en büyük SCN rakamını içerir.
Database NORMAL, TRANSACTIONAL, veya IMMEDIATE olarak kapatıldığında bütün
datafile header larına aynı SCN kaydedilir.
Bu numara(SCN) özellikle incomplete recovery sırasında çok kullanışlı olabilir.
Şu anki geçerli SCN değeri;
SELECT CURRENT_SCN FROM V$DATABASE;
veya
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAl;
sorgularıyla öğrenilebilir.
SCN , Flashback query ler içerisinde aşağıdaki şekilde kullanılabilir.
(Flashback query özelliği oracle 9i den itibaren kullanılmaya başlanmıştır.)
select *
from benim_tablo_adi
AS OF SCN 5713444761
where benim_id = 5
select *
from benim_tablo_adi
AS OF TIMESTAMP SYSDATE – 1/24;
where benim_id = 5
Aslında yukarıdaki iki query epey benzer query lerdir.
Çünkü her ikiside geçmiş bir zamandaki data kümesini
elde etmek amacındadır.
Yakından bakacak olursak aralarında önemli bir fark vardır.
İkinci sorgu her çalıştırmada farklı sonuç döndürebilir.
Fakat birinci sorgu eğer döndürebilirse hep aynı sonuç kümesini döndürür.
Döndürebilirse diyorum çünkü flashback konfigurasyonuna bağlı olarak
sadece 3 saat öncesini, 1 gün öncesini vs. flashback query ile görebilirsiniz.
Tabii bu storage, iş gereklilikleri, şirket politikaları vs. faktörlere bağlı
olarak oracle parametrelerinin düzenlenmesi ile olacaktır.
oracle database içerisinde tam olarak bir zamanı ifade eden, adı üstünde bir rakamdır.
Her transaction ın commit edilmesi ile beraber Oracle tarafından yeni bir SCN üretilir.
Oracle içerisinde, SCN isimli sıralı numaralar control file, datafile header ve redo kayıtlarında kullanır.
Her redo log dosyası bir log sequence numarası and low ve high SCN değerini içerir.
Low SCN kaydı ; log file içerisindeki en küçük SCN rakamını içerir.
High SCN kaydı ; log file içerisindeki en büyük SCN rakamını içerir.
Database NORMAL, TRANSACTIONAL, veya IMMEDIATE olarak kapatıldığında bütün
datafile header larına aynı SCN kaydedilir.
Bu numara(SCN) özellikle incomplete recovery sırasında çok kullanışlı olabilir.
Şu anki geçerli SCN değeri;
SELECT CURRENT_SCN FROM V$DATABASE;
veya
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAl;
sorgularıyla öğrenilebilir.
SCN , Flashback query ler içerisinde aşağıdaki şekilde kullanılabilir.
(Flashback query özelliği oracle 9i den itibaren kullanılmaya başlanmıştır.)
select *
from benim_tablo_adi
AS OF SCN 5713444761
where benim_id = 5
select *
from benim_tablo_adi
AS OF TIMESTAMP SYSDATE – 1/24;
where benim_id = 5
Aslında yukarıdaki iki query epey benzer query lerdir.
Çünkü her ikiside geçmiş bir zamandaki data kümesini
elde etmek amacındadır.
Yakından bakacak olursak aralarında önemli bir fark vardır.
İkinci sorgu her çalıştırmada farklı sonuç döndürebilir.
Fakat birinci sorgu eğer döndürebilirse hep aynı sonuç kümesini döndürür.
Döndürebilirse diyorum çünkü flashback konfigurasyonuna bağlı olarak
sadece 3 saat öncesini, 1 gün öncesini vs. flashback query ile görebilirsiniz.
Tabii bu storage, iş gereklilikleri, şirket politikaları vs. faktörlere bağlı
olarak oracle parametrelerinin düzenlenmesi ile olacaktır.
11 Haziran 2010 Cuma
Oracle Database Kurulumu Tavsiyeleri
Aşağıdaki öneriler tüm oracle database kurulumları için geçerli tavsiyeler
olmakla beraber, IFS özelinde bazı açıklamalar da eklemekte fayda görüyorum.
* Database server a Oracle dışında hiçbir uygulama kurmayın.
IFS Developer ı kendi bilgisayarınıza da kurabilirsiniz.
Gerekli yedekler ile ilgili bir politika oluşturduktan sonra başka
bir sorun oluşacağını düşünmüyorum.
Eğer developer dışı IFS software i kurulumuna ihtiyacınız var ise
başka bir server kullanın.
* Database server üzerinde dosya paylaşımı kullanmayın.
Kullanıcı dosyalarını oracle server oluşturduğunuz paylaşımlar
üzerinden sağlamanız duruma göre önemli miktarda; network bant genişliği kaybına ve
server io gereksinimi dolayısıyla performans sorunlarına yol açabilir.
ifs executable larına erişim dahil olmak üzere tüm share ihtiyacınızı oracle db server
dışı bir noktaya yönlendirin.
* Database server İşletim sistemi seviyesinde firewall ve antivirus kullanmayın.
Oracle database sunucunuzu fiziksel bir firewall arkasına alarak sadece belirli ip ve port yetkisi vermeniz yerinde olacaktır.
Örneğin tüm kullanıcılar 1521 portundan gelebilir ama ssh veya remote desktop sadece şu ip den gelebilir gibi.
* Mevcut sistem RAM inin %80 ini oracle a verin.
Gördüğüm IFS install larındaki oracle konfigurasyonları memory noktasında çok yanlış olabiliyor.
Mesela benim bire bir karşılaştığım bir durumda, server de 8 GB ram olmasına rağmen
oracle a 1 GB civarı ram verilmişti. Tabii bu "next" "next" diyerek oracle kurmaktan kaynaklanmakta :)
Tabii hal böyle olunce database ten performans beklememek lazım.
Ayrıca automatic memory managemet özelliğinin aktif olması da önemlidir.
Aksi taktirde tüm oracle memory sinin manual yönetimi gerekir.
Bu özellik 10g ve sonrasında mevcuttur.
Oracle db üzerindeki şu andaki mevcut ram durumunu aşağıdaki query ile veya oracle enterprise manager üzerinde "memory advisor" da
görebilirsiniz.
SGA total (değerler megabyte cinsinden)
-----------------------------------------
select round(sum(bytes)/1024/1024,2) total_sga,
round(sum(decode(name,'free memory',bytes,0))/1024/1024,2) free,
round((sum(decode(name,'free memory',bytes,0))/1024/1024)/(sum(bytes)/1024/1024)*100,2) free_per
from v$sgastat
PGA total (değerler megabyte cinsinden)
-----------------------------------------
select value/1024/1024 from v$pgastat where name = 'aggregate PGA target parameter'
* Oracle için işletim sistemi olarak mümkünse linux tercih edin.
Oracle ın linux üzerinde daha hızlı çalıştığı bilinen bir gerçektir. Ayrıca oracle linux üzerinde
geliştirildiğinden tum yeni versiyonlar ve güncellemeler öncelikle linux versiyonu olarak dağıtılır.
Evet "en iyi işletim sistemi bildiğin işletim sistemidir" cümlesine katılıyorum.
Fakat yeni fırsatlara da açık olmak gereklidir diye düşünüyorum.
Ayrıca kariyerini DBA olarak devam ettirmek isteyen herkes er yada geç linux ile tanışmak durumunda kalacaktır
desem yanlış olmaz heralde. Maliyetler nokatasında windows server lisans ücretleri de olayın başka bir tarafı.
Ayrıntılı karşılaştırma ve ekstra bilgi için aşağıdaki linkler faydalı olabilir.
http://www.dba-oracle.com/oracle_tips_linux_oracle.htm
http://www.oracle.com/us/technologies/linux/025994.htm
* 64 bit işletim sistemi kullanın.
32 bit sistemlerin bilinen kısıtlamalarına takılmamamak için 64 bit işletim sistemi tercih edin.
İyi çalışmalar.
olmakla beraber, IFS özelinde bazı açıklamalar da eklemekte fayda görüyorum.
* Database server a Oracle dışında hiçbir uygulama kurmayın.
IFS Developer ı kendi bilgisayarınıza da kurabilirsiniz.
Gerekli yedekler ile ilgili bir politika oluşturduktan sonra başka
bir sorun oluşacağını düşünmüyorum.
Eğer developer dışı IFS software i kurulumuna ihtiyacınız var ise
başka bir server kullanın.
* Database server üzerinde dosya paylaşımı kullanmayın.
Kullanıcı dosyalarını oracle server oluşturduğunuz paylaşımlar
üzerinden sağlamanız duruma göre önemli miktarda; network bant genişliği kaybına ve
server io gereksinimi dolayısıyla performans sorunlarına yol açabilir.
ifs executable larına erişim dahil olmak üzere tüm share ihtiyacınızı oracle db server
dışı bir noktaya yönlendirin.
* Database server İşletim sistemi seviyesinde firewall ve antivirus kullanmayın.
Oracle database sunucunuzu fiziksel bir firewall arkasına alarak sadece belirli ip ve port yetkisi vermeniz yerinde olacaktır.
Örneğin tüm kullanıcılar 1521 portundan gelebilir ama ssh veya remote desktop sadece şu ip den gelebilir gibi.
* Mevcut sistem RAM inin %80 ini oracle a verin.
Gördüğüm IFS install larındaki oracle konfigurasyonları memory noktasında çok yanlış olabiliyor.
Mesela benim bire bir karşılaştığım bir durumda, server de 8 GB ram olmasına rağmen
oracle a 1 GB civarı ram verilmişti. Tabii bu "next" "next" diyerek oracle kurmaktan kaynaklanmakta :)
Tabii hal böyle olunce database ten performans beklememek lazım.
Ayrıca automatic memory managemet özelliğinin aktif olması da önemlidir.
Aksi taktirde tüm oracle memory sinin manual yönetimi gerekir.
Bu özellik 10g ve sonrasında mevcuttur.
Oracle db üzerindeki şu andaki mevcut ram durumunu aşağıdaki query ile veya oracle enterprise manager üzerinde "memory advisor" da
görebilirsiniz.
SGA total (değerler megabyte cinsinden)
-----------------------------------------
select round(sum(bytes)/1024/1024,2) total_sga,
round(sum(decode(name,'free memory',bytes,0))/1024/1024,2) free,
round((sum(decode(name,'free memory',bytes,0))/1024/1024)/(sum(bytes)/1024/1024)*100,2) free_per
from v$sgastat
PGA total (değerler megabyte cinsinden)
-----------------------------------------
select value/1024/1024 from v$pgastat where name = 'aggregate PGA target parameter'
* Oracle için işletim sistemi olarak mümkünse linux tercih edin.
Oracle ın linux üzerinde daha hızlı çalıştığı bilinen bir gerçektir. Ayrıca oracle linux üzerinde
geliştirildiğinden tum yeni versiyonlar ve güncellemeler öncelikle linux versiyonu olarak dağıtılır.
Evet "en iyi işletim sistemi bildiğin işletim sistemidir" cümlesine katılıyorum.
Fakat yeni fırsatlara da açık olmak gereklidir diye düşünüyorum.
Ayrıca kariyerini DBA olarak devam ettirmek isteyen herkes er yada geç linux ile tanışmak durumunda kalacaktır
desem yanlış olmaz heralde. Maliyetler nokatasında windows server lisans ücretleri de olayın başka bir tarafı.
Ayrıntılı karşılaştırma ve ekstra bilgi için aşağıdaki linkler faydalı olabilir.
http://www.dba-oracle.com/oracle_tips_linux_oracle.htm
http://www.oracle.com/us/technologies/linux/025994.htm
* 64 bit işletim sistemi kullanın.
32 bit sistemlerin bilinen kısıtlamalarına takılmamamak için 64 bit işletim sistemi tercih edin.
İyi çalışmalar.
4 Haziran 2010 Cuma
IFS ortamının (Database,executable,develeoper vs) VMWARE üzerinde çalışır hale getirilmesi mümkün müdür?
Evet mümkündür. Bu şekilde çok ta işlevsel bir test sistemi oluşturulmuş olur.
Bazı firmaların production da bu tip sistemleri kullandığı da görülmedik bir şey değil LinkedIn gruplarından anladığım kadarı ile.
Tüm sistemin yedeğini almak için sanal makinayı kapatıp birkaç dosyanın kopyalanması çok cazip geliyor.
Örneğin 0-50 kullanıcı sayılı nispeten küçük database li bir production sistemi
bence vmware e de taşınabilir.
Taşıma işlemi aşağıdaki adımlardan oluşur.
1. Vmware üzerine, production da çalışan işletim sisteminin aynısı ve aynı versiyon oracle db kurulur.
Burada dikkat edilmesi gereken iki nokta vardır.
a. db create edilirken production daki oracle_sid neyse aynısını vermek gerekir.
b. Kurulan işletim sistemi ve oracle versiyonları production da kullanılanların aynısı olmalıdır.
2) Production ve vmware database kapatılır ve oracle dosyaları (datafile,redolog,controlfile vs) vmware üzerine aynı klasör yapısı ile kopyalanır.
3) Vmware üzerindeki database açılır ve IFS kurulum klasoru wmware içerisine kopyalanır ve install edilir.
4) Kullanılan exe, apx,api ne varsa onlar da aynı klasor yapısı ile vmware üzerine kopyalanır.
Bazı firmaların production da bu tip sistemleri kullandığı da görülmedik bir şey değil LinkedIn gruplarından anladığım kadarı ile.
Tüm sistemin yedeğini almak için sanal makinayı kapatıp birkaç dosyanın kopyalanması çok cazip geliyor.
Örneğin 0-50 kullanıcı sayılı nispeten küçük database li bir production sistemi
bence vmware e de taşınabilir.
Taşıma işlemi aşağıdaki adımlardan oluşur.
1. Vmware üzerine, production da çalışan işletim sisteminin aynısı ve aynı versiyon oracle db kurulur.
Burada dikkat edilmesi gereken iki nokta vardır.
a. db create edilirken production daki oracle_sid neyse aynısını vermek gerekir.
b. Kurulan işletim sistemi ve oracle versiyonları production da kullanılanların aynısı olmalıdır.
2) Production ve vmware database kapatılır ve oracle dosyaları (datafile,redolog,controlfile vs) vmware üzerine aynı klasör yapısı ile kopyalanır.
3) Vmware üzerindeki database açılır ve IFS kurulum klasoru wmware içerisine kopyalanır ve install edilir.
4) Kullanılan exe, apx,api ne varsa onlar da aynı klasor yapısı ile vmware üzerine kopyalanır.
18 Mayıs 2010 Salı
Flash Recovery Area büyüklüğü hatalı görünüyor. Nasıl doğru hale getirebilirim?
Bu sorun genellikle işletim sistemi seviyesinde backup/archivelog silinmesi veya donanım ağrızası sonucunda oluşur.
Sorunun nedeni ise RMAN in tuttuğu backup dosyaları ile ilgili datanın bir nedenle güncelliğini kaybetmiş olmasıdır.
RMAN komutlarından olan CROSSCHECK komutu daha onceden disk veya teybe alınmış olan backupset, image copy ve archived log dosyalarının kontrolü için kullanılır.
CROSSCHECK BACKUPSET; #backup parçalarını kontrol eder.
CROSSCHECK COPY; #datafile,control file, archived redo log ları kontrol eder.
CROSSCHECK archivelog all; #archivelog dosyalarini kontrol eder
CROSSCHECK komutu; işletim sistemi dosyalarını veya RMAN in tuttuğu dosyalar ile ilgili hatalı dataları silmez.
Sadece RMAN datasında bulunan, backup yada archive log dosyasının status/durum bilgisini günceller.
RMAN in varolan backup dosyaları ile ilgili tuttuğu datadan, artık diskte olmayan dosyaları kaldırmak için DELETE komutu kullanılır.
Expired backup veya copy lerin CROSSCHECK komutunun
çalıştırılması ardından silinmesi
***************************************************
CROSSCHECK komutu, kullanımına bağlı olarak RMAN repository(RMAN in backup, archivelog vs dosyalarını tuttuğu disk alanı) üzerinde kayıtlı
bulunan backup, archivelog vs. dosyalarının disk veya teyp üzerinde kontrol eder ve bulmadığı her dosyaya ait kendi tuttuğu
kaydı 'EXPIRED' olarak işaretler.
Daha sonra bu dosyaları RMAN repository den silmek için aşağıdaki komutlar kullanılır.
DELETE EXPIRED BACKUP;
DELETE EXPIRED COPY;
delete expired archivelog all;
Sorun : İşletim sistemi seviyesinde archive log dosyalarından bazılarını sildik. Flash Recovery Area büyüklüğü 50 gb fakat 80 gb gözüküyor.
Çözüm:
1.
RMAN>crosscheck archivelog all;
2.
RMAN>delete expired archivelog all;
veya aşağıdaki gibi script çalıştırılabilir.
V$BACKUP_FILES gorunumu RMAN repository de bulunan backup and copy lerini göstermektedir.
Diskte bulunan bütün backup ve copy lerin kontrolü ve RMAN repository düzeltmeleri için aşağıdaki script kullanılabilir.
run {
crosscheck backup;
crosscheck copy;
DELETE EXPIRED BACKUP;
DELETE EXPIRED COPY;
}
Sorunun nedeni ise RMAN in tuttuğu backup dosyaları ile ilgili datanın bir nedenle güncelliğini kaybetmiş olmasıdır.
RMAN komutlarından olan CROSSCHECK komutu daha onceden disk veya teybe alınmış olan backupset, image copy ve archived log dosyalarının kontrolü için kullanılır.
CROSSCHECK BACKUPSET; #backup parçalarını kontrol eder.
CROSSCHECK COPY; #datafile,control file, archived redo log ları kontrol eder.
CROSSCHECK archivelog all; #archivelog dosyalarini kontrol eder
CROSSCHECK komutu; işletim sistemi dosyalarını veya RMAN in tuttuğu dosyalar ile ilgili hatalı dataları silmez.
Sadece RMAN datasında bulunan, backup yada archive log dosyasının status/durum bilgisini günceller.
RMAN in varolan backup dosyaları ile ilgili tuttuğu datadan, artık diskte olmayan dosyaları kaldırmak için DELETE komutu kullanılır.
Expired backup veya copy lerin CROSSCHECK komutunun
çalıştırılması ardından silinmesi
***************************************************
CROSSCHECK komutu, kullanımına bağlı olarak RMAN repository(RMAN in backup, archivelog vs dosyalarını tuttuğu disk alanı) üzerinde kayıtlı
bulunan backup, archivelog vs. dosyalarının disk veya teyp üzerinde kontrol eder ve bulmadığı her dosyaya ait kendi tuttuğu
kaydı 'EXPIRED' olarak işaretler.
Daha sonra bu dosyaları RMAN repository den silmek için aşağıdaki komutlar kullanılır.
DELETE EXPIRED BACKUP;
DELETE EXPIRED COPY;
delete expired archivelog all;
Sorun : İşletim sistemi seviyesinde archive log dosyalarından bazılarını sildik. Flash Recovery Area büyüklüğü 50 gb fakat 80 gb gözüküyor.
Çözüm:
1.
RMAN>crosscheck archivelog all;
2.
RMAN>delete expired archivelog all;
veya aşağıdaki gibi script çalıştırılabilir.
run {
crosscheck archivelog all;
delete expired archivelog all;
}
V$BACKUP_FILES gorunumu RMAN repository de bulunan backup and copy lerini göstermektedir.
Diskte bulunan bütün backup ve copy lerin kontrolü ve RMAN repository düzeltmeleri için aşağıdaki script kullanılabilir.
run {
crosscheck backup;
crosscheck copy;
DELETE EXPIRED BACKUP;
DELETE EXPIRED COPY;
}
3 Mayıs 2010 Pazartesi
IFS kullanıcı grubu
Merhaba
Uzun zamandır IFS kullanıcılarının birbirleriyle bilgi/deneyim paylaşabilecekleri
bir platform olması gerektiğini düşünüyordum. Eminim bunu tek düşünen ben değilim :)
Artık böyle bir platform var. Tabi aktifliği Türkiye deki IFS kullanıcılarına bağlı olacaktır.
IFS ERP Turkiye Kullanici Grubu
http://www.linkedin.com/e/vgh/3012612/
Her ne kadar artık IFS developer/admin/user olmadığımı onceki postlarımda belirtmiş olsam da, zaman zaman bazı arkadaşların soruları mail kanalıyla gelmeye devam ediyor.
Düşündüm ki sorularımızı ve cevaplarımızı LinkedIn üzerine yazarsak, daha fazla kişinin deneyimlerinden faydalanabiliriz veye başka arkadaşlara da faydamız olabilir.
Saygılar.
Barış
Uzun zamandır IFS kullanıcılarının birbirleriyle bilgi/deneyim paylaşabilecekleri
bir platform olması gerektiğini düşünüyordum. Eminim bunu tek düşünen ben değilim :)
Artık böyle bir platform var. Tabi aktifliği Türkiye deki IFS kullanıcılarına bağlı olacaktır.
IFS ERP Turkiye Kullanici Grubu
http://www.linkedin.com/e/vgh/3012612/
Her ne kadar artık IFS developer/admin/user olmadığımı onceki postlarımda belirtmiş olsam da, zaman zaman bazı arkadaşların soruları mail kanalıyla gelmeye devam ediyor.
Düşündüm ki sorularımızı ve cevaplarımızı LinkedIn üzerine yazarsak, daha fazla kişinin deneyimlerinden faydalanabiliriz veye başka arkadaşlara da faydamız olabilir.
Saygılar.
Barış
26 Nisan 2010 Pazartesi
Oracle DB erişiminde OS Authentication nasıl iptal edilir?
Terminal ekranında aşağıdaki şekilde db erişimi
oracle db yi ilk kurduğumuzda açık durumdadır.
sqlplus / as sysdba
Ancak bu durum güvenlik açığı oluşturmaktadır. Engellemek
için ise sqlnet.ora dosyasında aşağıdaki satırın bulunmasını sağlamak yeterlidir.
SQLNET.AUTHENTICATION_SERVICES=(NONE)
sqlnet.ora dosyası $ORACLE_HOME/network/admin içerisinde bulunur.
Yani bir başka değişle tnsnames.ora dosyası ile aynı klasörde bulunur.
11gR2 database kurulumunun ardından sqlnet.ora dosyası $ORACLE_HOME/network/admin klasöründe yaratılmaz. Eğer bu dosyayı olması gereken yerde bulamıyorsanız siz oluşturun ve SQLNET.AUTHENTICATION_SERVICES=(NONE) satırını ekleyin.
Değişiklik anında etkili olmaya başlayacaktır. Yani db servisinin veya listener in yeniden başlatılması gerekli değildir.
Durumu eski haline çevirmek ve OS Authentication özelliğini yeniden kullanılabilir yapmak için aşağıdaki değişiklik yeterli olacaktır.
SQLNET.AUTHENTICATION_SERVICES=(ALL)
oracle db yi ilk kurduğumuzda açık durumdadır.
sqlplus / as sysdba
Ancak bu durum güvenlik açığı oluşturmaktadır. Engellemek
için ise sqlnet.ora dosyasında aşağıdaki satırın bulunmasını sağlamak yeterlidir.
SQLNET.AUTHENTICATION_SERVICES=(NONE)
sqlnet.ora dosyası $ORACLE_HOME/network/admin içerisinde bulunur.
Yani bir başka değişle tnsnames.ora dosyası ile aynı klasörde bulunur.
11gR2 database kurulumunun ardından sqlnet.ora dosyası $ORACLE_HOME/network/admin klasöründe yaratılmaz. Eğer bu dosyayı olması gereken yerde bulamıyorsanız siz oluşturun ve SQLNET.AUTHENTICATION_SERVICES=(NONE) satırını ekleyin.
Değişiklik anında etkili olmaya başlayacaktır. Yani db servisinin veya listener in yeniden başlatılması gerekli değildir.
Durumu eski haline çevirmek ve OS Authentication özelliğini yeniden kullanılabilir yapmak için aşağıdaki değişiklik yeterli olacaktır.
SQLNET.AUTHENTICATION_SERVICES=(ALL)
9 Nisan 2010 Cuma
ORACLE - EM Backup job ları hakkında
Bir backup job oluşturmak için EM kullandığınızda, bu job ile ilgili bilgiler SYSMAN.MGMT_JOB tablosunda depolanır.
DBA_JOBS veya USER_JOBS tablosunda bu job ile ilgili bilgi bulunmaz.
Tüm EM backup jobları görüntülemek için SYSMAN.MGMT_JOB tablosu sorgulanmalıdır.
Alternatif olarak EM içerisinde "Availability" tabında, alt tarafındaki linler arasında bulunan "Jobs" linkinden de görüntülenebilir.
Ayrıca EM kapalı iken bu tip backup job larının da çalışmayacağı unutulmamalıdır.
DBA_JOBS veya USER_JOBS tablosunda bu job ile ilgili bilgi bulunmaz.
Tüm EM backup jobları görüntülemek için SYSMAN.MGMT_JOB tablosu sorgulanmalıdır.
Alternatif olarak EM içerisinde "Availability" tabında, alt tarafındaki linler arasında bulunan "Jobs" linkinden de görüntülenebilir.
Ayrıca EM kapalı iken bu tip backup job larının da çalışmayacağı unutulmamalıdır.
23 Mart 2010 Salı
Linux - Açılışta script çalıştırma
root olarak script çalıştırmak için :
/etc/rc.local
dosyasını edit ederek çalıştırılacak script i ekleyebilirsiniz.
Eğer başka bir kullanıcı session açılışında
bir script çalıştıracaksanız :
/home/user_neyse_o/bash_profile
dosyasını edit ederek çalıştırmak istediğiniz script i ekleyebilirsiniz.
Örn : Burada "oracle" kullanıcı adı. Editor olarak vi kullanıyoruz.
[oracle@bizimserver ~]$ pwd
/home/oracle
[oracle@bizimserver ~]$vi .bash_profile
/etc/rc.local
dosyasını edit ederek çalıştırılacak script i ekleyebilirsiniz.
Eğer başka bir kullanıcı session açılışında
bir script çalıştıracaksanız :
/home/user_neyse_o/bash_profile
dosyasını edit ederek çalıştırmak istediğiniz script i ekleyebilirsiniz.
Örn : Burada "oracle" kullanıcı adı. Editor olarak vi kullanıyoruz.
[oracle@bizimserver ~]$ pwd
/home/oracle
[oracle@bizimserver ~]$vi .bash_profile
11 Mart 2010 Perşembe
Linux - Crontab kullanarak tekrarlayan işlerin başarımı
Linux işletim sistemi; bir programı veya scripti belirli bir zamanda, bir defaya mahsus olarak veya tekrarlayan şekilde çalıştırmayı desteklemektedir. Bu makalede, periyodik şekilde tekrarlayan işlerin Linux üzerinde "cron" ile nasıl başarılacağını anlatmaya çalışacağım.
Crond servisi, her dakika cron job larını kontrol eder ve çalışma zamanı gelen job lar çalıştırılır. crond servisi ,eğer siz kapatmadıysanız, her açılışta çalışır durumdadır. Bir görev en az 1 dk. da bir çalıştırılabilir. 1 dk. dan daha kısa süreli bir tekrar çalıştırma söz konusu ise cron işinizi görmeyecektir.
Şimdi ,aşağıdaki örnek sh scriptini her 5 dakikada bir çalıştırarak kavramları açıklayacağım.
Örnek sh scripti
****************************
[oracle@oradb ~]$ cat mycrontest.sh
#!/bin/bash
echo "Saat simdi $(date +%T) - $(date +%A)"
[oracle@oradb ~]$ ./mycrontest.sh Saat simdi 18:37:42 - Friday
****************************
Yukarıdaki scripti 5 dk. da bir çalıştıracak crontab girişini yapalım.
****************************
[oracle@oradb ~] crontab -e
yukarıdaki komutu çalıştırdığınızda, çalıştırdığınız kullanıcıya ait zamanlanmış
görev listesi vi editörüne gelir. Aşağıdaki satıra vi editörüne ekleyip kaydetmemizin ardından mycrontest.sh scriptimiz her 5 dk. da bir çalışacaktır.
*/5 * * * * /home/oracle/mycrontest.sh
Yukarıdaki örnek job setup satırının açıklamaları aşağıdaki gibidir.
script_dosyasi : /home/oracle/mycrontest.sh
* * * * * script_dosyasi
- - - - -
| | | | |
| | | | +----- day of week (0 - 6) (Sunday=0)
| | | +------- month (1 - 12)
| | +--------- day of month (1 - 31)
| +----------- hour (0 - 23)
+------------- min (0 - 59)
Bu konuda bir örnek daha vereyim. Örneğin aynı script dosyasını
her gün sabah 04:15 çalıştırmak için aşağıdaki satır cron jobları
arasına eklenebilir.
crontab -e
15 4 * * * /home/oracle/mycrontest.sh
****************************
Cron job görüntüleme ve tüm cron jobları silme
****************************
[oracle@oradb ~]$ crontab -l
5 * * * * /home/oracle/mycrontest.sh
[oracle@oradb ~]$ crontab -r
[oracle@oradb ~]$ crontab -l
no crontab for oracle
Yukarıdaki şekilde crontab -r komutu ile geçerli user için crontab boşaltılabileceği gibi isterseniz crontab -e kullanarak da görev ekleme, çıkarma veya görevlerde değişiklikler yapabilirsiniz.
Ek olarak aşağıdaki linkleri inceleyebilirsiniz.
Türkçe
----------------
http://www.belgeler.org/man/man5/man5-crontab.html
İngilizce
----------------
http://adminschoice.com/crontab-quick-reference
Crond servisi, her dakika cron job larını kontrol eder ve çalışma zamanı gelen job lar çalıştırılır. crond servisi ,eğer siz kapatmadıysanız, her açılışta çalışır durumdadır. Bir görev en az 1 dk. da bir çalıştırılabilir. 1 dk. dan daha kısa süreli bir tekrar çalıştırma söz konusu ise cron işinizi görmeyecektir.
Şimdi ,aşağıdaki örnek sh scriptini her 5 dakikada bir çalıştırarak kavramları açıklayacağım.
Örnek sh scripti
****************************
[oracle@oradb ~]$ cat mycrontest.sh
#!/bin/bash
echo "Saat simdi $(date +%T) - $(date +%A)"
[oracle@oradb ~]$ ./mycrontest.sh Saat simdi 18:37:42 - Friday
****************************
Yukarıdaki scripti 5 dk. da bir çalıştıracak crontab girişini yapalım.
****************************
[oracle@oradb ~] crontab -e
yukarıdaki komutu çalıştırdığınızda, çalıştırdığınız kullanıcıya ait zamanlanmış
görev listesi vi editörüne gelir. Aşağıdaki satıra vi editörüne ekleyip kaydetmemizin ardından mycrontest.sh scriptimiz her 5 dk. da bir çalışacaktır.
*/5 * * * * /home/oracle/mycrontest.sh
Yukarıdaki örnek job setup satırının açıklamaları aşağıdaki gibidir.
script_dosyasi : /home/oracle/mycrontest.sh
* * * * * script_dosyasi
- - - - -
| | | | |
| | | | +----- day of week (0 - 6) (Sunday=0)
| | | +------- month (1 - 12)
| | +--------- day of month (1 - 31)
| +----------- hour (0 - 23)
+------------- min (0 - 59)
Bu konuda bir örnek daha vereyim. Örneğin aynı script dosyasını
her gün sabah 04:15 çalıştırmak için aşağıdaki satır cron jobları
arasına eklenebilir.
crontab -e
15 4 * * * /home/oracle/mycrontest.sh
****************************
Cron job görüntüleme ve tüm cron jobları silme
****************************
[oracle@oradb ~]$ crontab -l
5 * * * * /home/oracle/mycrontest.sh
[oracle@oradb ~]$ crontab -r
[oracle@oradb ~]$ crontab -l
no crontab for oracle
Yukarıdaki şekilde crontab -r komutu ile geçerli user için crontab boşaltılabileceği gibi isterseniz crontab -e kullanarak da görev ekleme, çıkarma veya görevlerde değişiklikler yapabilirsiniz.
Ek olarak aşağıdaki linkleri inceleyebilirsiniz.
Türkçe
----------------
http://www.belgeler.org/man/man5/man5-crontab.html
İngilizce
----------------
http://adminschoice.com/crontab-quick-reference
Kaydol:
Kayıtlar (Atom)