Weblogic, Admin Console için lokal kullanıcılara ait şifre bilgilerini lokal LDAP yapısı içerisinde tutmaktadır. Console üzerinde yeni bir kullanıcı oluşturduğunuzda bu kullanıcı Weblogic’e gömülü LDAP üzerinde saklanmaktadır ve bu LDAP yapısı üzerinden yönetilmektedir.
Weblogic yönetim panellerine ait domain’in sahibi bir ana kullanıcı bulunmaktadır. Genellikle de bu kullanıcının varsayılan ismi ‘weblogic’ olarak verilmektedir. Farklı nedenlerden dolayı bu kullanının şifresini değişitirmek isteyebilirsiniz. Ya da bu kullanıcının şifresini resetlemek de isteyebilirsiniz. Bu tür durumlarda aşağıdaki yol haritasını izleyerek şifre değişikliği işlemini başarıyla gerçekleştirebilirsiniz.

1. ‘Middleware home’ ve ‘Domain home’ değişkenleri aşağıdaki gibi export edilmelidir;

export MW_HOME=/u01/app/oracle/middleware 
export DOMAIN_HOME==/u01/app/oracle/domain/test

2. Weblogic Admin Console’u kapatırız.

$DOMAIN_HOME/bin/stopWebLogic.sh

3. Data dizininin yedeğini alırız.

mv $DOMAIN_HOME/servers/AdminServer/data $DOMAIN_HOME/servers/AdminServer/data-old

4. Ortam değişkenleri aşağıdaki script yardımıyla set edilmelidir;

. $DOMAIN_HOME/bin/setDomainEnv.sh

5. Admin server altındaki ‘security’ dizini altında ‘DefaultAuthenticatorInit.ldift’ dosyasının yedeği alınmalıdır;

cd $DOMAIN_HOME/security
mv DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift_backup

6. Aşağıdaki komut yardımıyla yeni şifre belirlenmelidir. Burada varsayılan domain sahibi kullanıcının ‘weblogic’ olduğu düşünülerek yazılmıştır. yeni şifre yazıldıktan sonra bir boşluk ve nokta karakteri unutulmamalıdır. Bu komut koşturulduktan sonra yeni ldift dosyası oluşacaktır.

cd $DOMAIN_HOME/security
java weblogic.security.utils.AdminAccount weblogic yeni_sifre .

7. Eğer boot.properties dosyası daha önceden set edilmişse ve kullanılıyorsa bu dosya içerisinde de yeni kullanıcı adı ve şifre yedeği alındıktan sonra güncellenmelidir;

$DOMAIN_HOME/servers/AdminServer/security
cp boot.properties boot_old.properties
cat boot.properties
username=weblogic
password= yeni_sifre

8. Son adım olarak domain varsayılan start komutu yardımıyla ayağa kaldırılarak yeni kullanıcı adı ve şifre ile login olunabilir;

$DOMAIN_HOME
nohup ./startWebLogic.sh >> startWebLogic.out &
tail -f startWebLogic.out

Hata oluşma ihtimali mevcut ve hata oluşması durumunda en azından yeni yapı çalışmıyor olsa bile eskiye geri dönebiliyor olmamız gerekir. Eğer bir hata ile karşılaşılırsa aldığımız backup dosyalarına geri dönülerek domain değişiklik öncesi hali ile çalıştırılabilir.

Mustafa Bektaş Tepe

İyi Çalışmalar

Bir veritabanı sisteminde SQL çalıştırdığımız zaman arka planda nelerin olduğunu bilmek önemli. Bilindiği takdirde örneğin “bind variable kullanımı”, “bulk işlemler” vb. durumlarda Oracle tarafında olan işlemlerin nasıl etkilendiği farkında olunacak ve buna göre bir yaklaşım belirlemek mümkün olacaktır.

SQL işlemleri 2 ana başlık altında toplanır :

• DDL(Data Definition Language) : “Data Dictionary” üzerinde değişikliğe sebeb olan create, drop, alter gibi işlemlerdir.
• DML(Data Manipulation Language) : Veriye ulaşmak ya da değiştirmek amacıyla yapılan işlemlerdir.(Select, update,delete…vs.)

SQL Processing işlemi parsing, optimization, row source generation ve execution adımlarından oluşur. Sql ifadesine göre bazı adımlar atlanabilir.

SQL Parsing

Yukarıdaki diyagramda gözüktüğü üzere SQL işlemesinin ilk aşaması SQL sorgusunun parse edilmesidir. Parse etmeyi şöyle açıklayabilirim. Bir uygulamaya ya da bir operasyona anlamlı gelecek şekle getirmektir. Binary bir dosyayı parse ederek CSV formatında bir dosyaya çevirirseniz, sizin için anlamlı bir hale gelecektir ancak öncelikle parser’ın binary dosyanın dilinden anlıyor olabilmesi ve sizin elinizde bunu tercüme edecek bir dokümantasyonun bulunması gerekmektedir. Oracle’ın yaptığıda aslında bundan çok farklı değildir. Oracle da kendisi için anlamlı gelecek bir format oluşturmaya çalışır fakat sistematiği biraz farklıdır.

Bir sql ifadesi çalıştırılacağı zaman veritabanı üzerinde parse call talebi ile veritabanı üzerinde cursor açılır. Bu cursor session bazlı açılır ve private SQL area üzerinde tutulur. Cursor ve private SQL area program global area (PGA) içindedir. Parse call işlemi 3 aşamadan oluşur.

• Syntax check
• Semantic check
• Shared pool check

(continue reading…)

Tablo ve sütun istatistikleri, optimizer a çok şey anlatır, ancak Optimizera tablodaki veya sütundaki verilerin çeşitliliğini bildiren bir mekanizma sağlamaz. Örneğin, bu istatistikler sütunda verilerin skew data (çarpık/birbiriyle kesişmeyen veri) olup olmadığını veya bir tablodaki sütunlar arasında bir korelasyon olup olmadığını (farklı sütunlar arasındaki doğrusal ilişkinin yönü ve gücü) Optimizer’e söyleyemez. Verilerin çeşitliliği hakkındaki bilgiler, histogramlar, sütun grupları (column groups) ve sorgu istatistikleri gibi temel istatistiklerin uzantıları kullanılarak Optimizer’e sağlanabilir.

Histograms

Histogramlar, Optimizer ‘a bir sütundaki verilerin dağılımını anlatır.  Varsayılan olarak (histogram olmadan), Optimizer, bir sütundaki belirsiz değerler arasında tek bir satır dağılımını varsayar. (yani hep aynı değerde veri varmış gibi düşünür)

Yukarıda tarif edildiği gibi, Optimizer, bir eşitlik öngörüsünün kardinalitesini, tablodaki toplam satır sayısını eşitlik yüklemesinde kullanılan sütundaki farklı değerlerin sayısına bölerek hesaplar. Sütundaki veri dağılımı uniform (tekdüze) değilse (yani veri skew (çarpık) ise) kardinalite testi yanlış olacaktır. Düzgün olmayan bir veri dağılımını doğru bir şekilde yansıtmak için sütunda bir histogram gerekir. Histogramın varlığı, Optimizer tarafından cardinality’i tahmin etmek için kullanılan formülü değiştirir ve daha hassas bir uygulama planı oluşturmasını sağlar.

Oracle, sütun kullanım bilgilerine (SYS.COL_USAGE $) ve veri eğrilmesinin öncülüğünü esas alarak histogramlara ihtiyaç duyan sütunları otomatik olarak belirler.

Oracle, sütun kullanım bilgilerine (SYS.COL_USAGE $) ve skew veriye(çarpık)  bağlı olarak histogramlara ihtiyaç duyan sütunları otomatik olarak belirler. Örneğin, bir sütunda unique alan var ve yanlızca eşitlik var mıdır yok mudur şartı gelirse Oracle histogram oluşturmaz.

İki tip histogram vardır; frequency veya height-balanced. Oracle, sütundaki farklı değerlerin sayısına göre oluşturulacak histogram türünü belirler. (continue reading…)

Sysstat rpm paketi ile yüklenen çok kullanılan komutlardan birisidir.

Bu komutla network file systems ve disklere dair I/O ve CPU istatistiklerine erişilebilir. Parametre kullanılmadan çalıştırıldığında sistemin son açılmasından itibaren disk ve CPU kullanımı ile ilgili bilgi verir.

iostat komutuna verilecek ilk rakamsal parametre kaç saniyede bir rapor üretileceğini, 2. parametre ise ekrana kaç defa çıktı verileceğini belirtir. Eğer 2. parametre verilmezse istenen zaman aralığı için ekrana sürekli olarak sistem bilgisi basılacaktır, birçok işlemde olduğu gibi bu işlem de Ctrl+C ile sonlandırılabilir.

Parametre olarak diskin ismi de verilip özelleştirilmiş bir rapor alınabilir.

• -d : Sadece disk kullanım bilgisi görülür.
• -c : Sadece işlemci(CPU) kullanım bilgisi izlenir.
• -k : istatistikleri blok cinsinden değil KB cinsinden verir
• -m : istatistikleri MB cinsinden gösterir
• -p : Belirli bir disk izlenebilir.
• -x : Genişletilmiş istatistikler için
• -n : Sadece NFS ile bağlı diskler ile ilgili bilgi verir
• -t : İstatistik bilgisinin yanında ayrıntılı zaman bilgisinide verir.

(continue reading…)

Bir tabloda sürekli olarak belirli satırları sorguluyor ya da değiştiriyorsanız, her seferinde diske gitmeniz mantıklı olmaz. Çünkü I/O maliyetli bir işlemdir. Bu yüzden bellek performans için can simididir. Sıkça okuduğunuz ya da sıkça değiştirdiğiniz şeyleri her seferinde diske yazmak ya da diskten okumak yerine bunu bellekte kotarabilirseniz, performansı arttırabilirsiniz. Bellekte çalışmak performans konusunda artış sağladığından Oracle da böyle yapar; diskte çalışmak yerine mümkün olduğunca belleği kullanır. İşte bu yüzden bir sorguyu ikinci defa çalıştırdığınızda, sonuçlar daha hızlı gelir. Çünkü sorguda kullanılan block’lar hâlâ ‘sıcaktır’ ve diske hiç gitmeden, direkt bellekten sonuç döner. Bellekte yer kalmadığında, daha sıcak (kullanım sıklığı daha fazla) olan block’lar, soğuk (kullanım sıklığı daha az) block’ların yerini alır. Oracle kapalı bir yazılım olduğundan arka plânda ne olduğunu elbette bilemiyoruz. Ama zekice yazılmış bir Least Recently Used – LRU algoritmasıyla bu işin yapıldığını tahmin edebiliriz.
İşlemlerin bellekte gerçekleştirilmesi güzel bir olay. Ama bazı durumlarda (performans problemleriyle karşı karşıya kaldığımızda ya da testlerin daha tutarlı olması gerektiğinde) Oracle’a bazı komutlarla müdahele etmemiz gerekir.

1. BUFFER CACHE

Oracle’da birçok şey sadece bellekte tamamlanıyor. Örneğin bir DML işlemi (insert, update, delete) yaptığınızda gidip veritabanı dosyalarına yazması gerekmez. Ya da bir sorgu çalıştırdığınızda, sorgu biter bitmez, veri saklayan block’ların bellekten atılması gerekmez. Block’lar sorgulara göre bellekte tutulabilir. Hatta çalıştırdığınız sorgular, diske hiç erişmeden sonuç dönüyor olabilir. Bununla ilgili bir örnek üzerinden gidelim. Önce aşağıdaki gibi tabloyu yaratıyoruz:

create table test as select * from dba_objects;

Yarattığımız tabloda toplamda 96.760 kayıt var ve tablonun bulunduğu tablespace’te her block 8K’dan oluşuyor. DBA_SEGMENTS’ten baktığımda tablonun 11.534.336 byte (11MB) kapladığını ve 1408 block’tan oluştuğunu görüyorum. Tablo istatistiklerini topladığımdaysa, 1387 block görünüyor. (Block boyutunu 1K’ya kadar indirip, PCTFREE değerini düşürebilseydik; bu ikisi arasındaki fark daha da ufak olabilirdi.)
Sırada basit bir sorgu yazmak var:

SELECT COUNT(*)FROM test WHERE OBJECT_ID >1000;

Şimdi de sorgunun ne kadar disk okuması yaptığına bakalım.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    1395          1           1450

Buradaki DISK_READS, okunan block sayısı; EXECUTIONS ifadenin kaç kere çalıştığı; BUFFER_GETS ise SQL ifadesi nedeniyle bellekten ne kadar blockokunduğunu gösteriyor. Bunları daha iyi görebilmek için aynı sorguyu defalarca çalıştırıyorum:
Sorguyu defalarca çalıştırdıktan sonra, EXECUTIONS sayısı arttığı hâlde DISK_READS artmıyor, fakat BUFFER_GETS ciddi bir artış gösteriyor. Yani SQL’in diske gitmeden sürekli bellekten sonuç döndüğünü görebiliyoruz. Bu güzel bir özellik ama eğer bir SQL’i test ediyor olsaydım, sonuçları sürekli bellekten okumak beni yanıltırdı. Bu gibi durumlar için bellekteki block’ları boşaltmak daha doğru sonuçlar elde etmemi sağlar. Burada aşağıdaki komutla manüel olarak buffer cache’in içini boşaltıyoruz.

ALTER SYSTEM FLUSH BUFFER_CACHE;

Özetle FLUSH BUFFER_CAHCE yaparsanız;
• Bellekte tutulan block’lar atılır.
• Dirty Buffers (değişime uğramış ama diske yazılmamış, bellekte tutulan block’lar) diske yazılır
• SQL Plan bozulmaz
• SQL ile ilgili istatistikler silinmez

2.SHARED POOL

İlk kez çalışan SQL ifadeleri hard parse yapılır. SQL ifadesi hash’lenerek ona özel bir kimlik (SQL_ID) verilir; ihtimaller hesaplanarak en uygun (cost’u en düşük) plan belirlenir. Bu masraflı bir iştir; CPU’ya maliyeti vardır. Bu yüzden plan tekrar tekrar hesaplanmaz. Aynı ifade söz konusu ise aynı plan üzerinden gidilir. Bu güzel bir özellik ama bazı zamanlar operasyonumuz sonrası SQL’imiz için yeni bir execution plan oluştursuz isteriz. Bu gibi durumlardan sakınmak için shared pool’u boşaltmak bir çözümdür;

ALTER SYSTEM FLUSH SHARED_POOL;

Yukarıda anlattıklarım zaten bilinen şeyler. Fakat göstermek istediğim bir durum var. Aşağıdaki sorguyu çalıştırırsanız artık sonuç boş gelecektir –ki bu beklediğimiz bir şey. Çünkü SQL ID ve buna bağlı her şey gidiyor.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
no rows selected.

Şimdi ilk sorgumuzu tekrar çalıştırıp, disk okumalarına bakalım:

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    0          1           1450

İlk defa çalıştırıldığı ve sql plan ilk defa hazırlandığı hâlde, hiç disk okuması yapılmıyor.
Özetle FLUSH SHARED_POOL yaparsanız;
• Bütün SQL planları ve bellekte tutulan SQL bilgilerini atarsınız.
• Ancak bu buffer cache’te tutulan data block’larını etkilemez. Daha önce eriştiğiniz block’lar hâlâ bellektedir. (continue reading…)

Dosya sistemini oluşturduktan sonra sistem yöneticisi tarafından bazı bakımların yapılması gerekebilir. Bu bakım ve dosya sistemindeki bazı parametre değişiklikleri tune2fs komutu ile yapılabilmektedir.

Tune2fs komutu ext2,ext3 ve ext4 dosya sistemlerine kullanılabilmektedir. Tunefs ile yapılabilecek bazı değişiklikler:

• Dosya sistemleri arası geçiş. Örn. Ext2’den ext3’e geçiş
• fsck işleminin yapılması için geçmesi gereken zaman aralığı veya mount sayısını belirler (-c ve –i parametreleri)
• Mevcut dosya sistemi hakkında bilgiler verir. (-l parametresi)

Modern dosya sistemleri hatalara karşı dayanıklılığı arttırmak için journal (günlük) tutarlar. Dosya sisteminde herhangi bir işlem yapılmadan önce günlüklere kaydedilir. Daha sonra yapılacak olan iş yerine getirilir. Dosya sisteminde herhangi bir hata meydana geldiğinde günlüklerdeki muamele girdileri konrol edilerek hata düzeltilmeye çalışılır. Günlüklü dosya sistemleri, günlüksüz olanlara göre çok daha hızlı bir dosya sistemi kurtarma işlemi gerçekleştirebilir. Örneğin ani güç kesilmesi durumunda fsck aracı dosya ve dizinleri teker teker kontrol etmek yerine günlük girdileri kontrol edilir. Böylece dosya sistemini bozulmadan önceki durumuna kolayca çevirebilir. Linux ext2 dosya sistemi günlüğe sahip değildir. Ext3 dosya sistemi ise günlük kullanır. Eğer dosya sisteminiz ext2 ise ve ext3 dosya sistemine terfi etmek istiyorsanız, bu terfi işlemini biçimlendirme (format) işlemine gerek kalmadan gerçekleştirebilirsiniz. Bunun için;

tune2fs -j /dev/hdd3

Mustafa Bektaş Tepe

İyi Çalışmalar