29 Aralık 2011 Perşembe

Yeni Başlangıçlar için 2012

Merhabalar,

Günlüğümü takip eden herkese sağlıklı, huzurlu ve mutlu yeni bir yıl dilerim. Umarım her şey dilediğiniz gibi olur.

2011'e dönüp baktığımda belkide hayatımdaki en önemli yıllardan birini geçirdiğimi söyleyebilirim (evliliğimden sonra :). Sırasıyla; Ocak 2011'de OCA, Şubat 2011'de OCP sertifikalarını aldıktan sonra 1 Ağustos 2011'den geçerli olmak üzere Oracle'da kıdemli satış danışmanı pozisyonuna geçtim. Bu sene toplamda 50'den fazla makale yazdım ve Ocak 2008'den beri yazdığım günlüğümdeki en çok makale yayımladığım yıl, 2011 oldu. Seminerlere katıldık, tartıştık, sunum yaptık ve paylaşımlarımıza devam ettik. Her şeyden önemlisi, bütün bunlar olurken çok şükür sağlığımız ve ağzımızın tadı bozulmadı.

2012 yılında hedefim 60'dan fazla makale yayımlamak, daha çok Oracle seminerine katılmak, Oracle olarak çok daha fazla Üniversitede "Are You Job Ready" sunumları gerçekleştirerek, yüzlerce öğrenciye iş hayatıyla ilgili bilgiler aktarmak. Bu sene Oracle günlüğümde işletme yönetimiyle ilgili birkaç makale daha yayımlamayı planlıyorum. Biraz daha farklı bir açıdan işleri ele almak istiyorum ve makalelerin içeriği okumayı çok sevdiğim organizasyon kültürü ve değişimleri ile ilgili olabilir.

Bu sene Türkiye'deki Oracle topluluğunun daha fazla büyümesini, daha çok sertifikalı uzmanın sektörde yer almasını, insanların daha fazla paylaşımda bulunmasını ve ACE ödüllerinin devam etmesini umuyorum. Üniversitelerdeki sunumlarımızı takip etmek isterseniz linkedin profilimden tarih ve üniversite bilgilerini öğrenebilirsiniz.

Herkese iyi seneler!

Ogan

23 Aralık 2011 Cuma

SWITCH DATAFILE ALL ve ORA-01157

Merhaba,

ORA-01157 hatasıyla ilgili tecrübelerimi aktarmak istiyorum. Hatanın tam açılımı aşağıdaki gibidir;

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
Bu hatanın Türkçe karşılığı şu, kontrol dosyası data file 1'i bulamıyor ve DBWR trace dosyasına konuyla ilgili bir bilgi basılıyor. Kontrol dosyasının içinde bütün data file'ların SCN'leri ile birlikte bilgileri tutulmaktadır. SCN'si geride olan bir data file olduğu durumda ya da ilgili data file fiziksel olarak yerinde olmadığında veya fiziksel olarak yerinde olsa bile kontrol dosyasında adı başka türlü gözüküyorsa veritabanını open moduna getiremezsiniz. Buradaki hatanın oluşma nedenlerinden birisini göstereceğim.

Öncelikle veritabanımızın bir yedeğini alıyoruz;

RMAN> backup database;
Sonra başka bir ortamda restore işlemi yapıyoruz;

run {
restore spfile from autobackup;
restore controlfile from autobackup;
restore database;
recover database;
}

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '+DATA/orcl/datafile/system.256.659541263'

SQL>
Bu hatayı almış olmanızın muhtemel nedeni her iki tarafında ASM olması ve db_file_name_convert parametrenizin ayarlanmamış veya SET NEWNAME FOR DATAFILE komutu ile datafile'ların yeni yerlerini kontrol dosyasına nasıl restore etmesi gerektiğini göstermemiş olmanızdır. Yalnız, ASM'de şöyle de bir durum var ki ASM instance'ı her restore'dan sonra datafile'ların isim uzantılarına değiştiriyor EĞER ilgili datafile başka bir ASM disk grubundan restore edilmişse. Bu durumda gönderdiğiniz SET NEWNAME FOR DATAFILE komutuna ya da ayarladığınız DB_FILE_NAME_CONVERT parametresine ek olarak --> SWITCH DATAFILE ALL; komutunu da run bloğunda vermeniz gerekiyor. Bu komutla data file'ın ASM bilgileri, kontrol dosyasında restore edildiği gibi değiştiriliyor ve veritabanını open resetlogs açabiliyorsunuz.


run{
SWITCH DATAFILE ALL;
}

datafile 1 switched to datafile copy
input datafile copy recid=1 stamp=677435474 filename=+DATA/orcl/datafile/system.291.677435389
datafile 2 switched to datafile copy
input datafile copy recid=2 stamp=677435474 filename=+DATA/orcl/datafile/undotbs1.304.677435423
datafile 3 switched to datafile copy
input datafile copy recid=3 stamp=677435474 filename=+DATA/orcl/datafile/sysaux.284.677435369
datafile 4 switched to datafile copy
input datafile copy recid=4 stamp=677435474 filename=+DATA/orcl/datafile/users.307.677435423
datafile 5 switched to datafile copy
input datafile copy recid=5 stamp=677435474 filename=+DATA/orcl/datafile/undotbs2.303.677435421
datafile 6 switched to datafile copy
input datafile copy recid=6 stamp=677435474 filename=+DATA/orcl/datafile/undotbs3.299.677435417

switch komutunu teker teker de verebilirsiniz;

RMAN> switch datafile 1 to copy;

datafile 1 switched to datafile copy
input datafile copy recid=1 stamp=677435474 filename=+DATA/orcl/datafile/system.291.677435389

Bir ASM instance'ından diğer bir ASM instance'ına geçiş yaparken her zaman switch datafile all; komutunu vermeniz gerekmiyor aslında. Örneğin bir Exadata makinesinde varsayılan olarak 3 tane ASM instance'ı vardır. Bunlardan birincisi DATA diğeri SYSTEM ve diğeri de RECO. Backup'ını aldığınız veritabanındaki bütün datafile'lar DATA'da ise restore ederken switch datafile all; komutunu vermeniz gerekmiyor. Ancak, diyelim backup'ını aldığınız veritabanındaki datafile'ların yanlışlıkla RECO'da yaratılmış. Bir kısmının bu şekilde olduğunu düşünün. Bu durumda o datafile'lar için switch datafile all; komutunu vermeniz gerekiyor çünkü SET NEWNAME FOR DATAFILE komutu ile isim ayarlamak isteseniz bile ASM disk grubu değişince datafile'ın sonundaki uzantı da değişiyor. Bu değişikliği switch komutu ile de kontrol dosyasına göstermek gerekiyor.

Bu makaledeki önemli nokta ve vermek istediğim mesaj, yukarıdaki yoldan geçtiyseniz veritabanının tamamını yeniden restore etmeye çalışmayın ve vakit kaybetmeyin. Belirttiğim komutla işleri yoluna koyabilirsiniz.

İyi çalışmalar.

Ogan

2 Kasım 2011 Çarşamba

DDL_LOCK_TIMEOUT

Merhaba,

Bugün bana gelen bir soru üzerine bu makaleyi yazmaya karar verdim. Öncelikle soru ile başlıyorum;

"
Arka arkaya birkaç insert işleminden sonra ORA-00054: resource busy and acquire with NOWAIT specified hatası alıyorum ama bu hatayı almadan, belirli bir süre boyunca session'ın beklemesini istiyorum
"

ORA-00054 hatasını almamızın nedeni; A session'ı ilgili tablo üzerinde "exclusive lock" olarak bildiğimiz bir DML kilit alırsa, B session'ı da ALTER TABLE gibi bir DDL komutunu yine ilgili tablo için gönderirse, gelen DDL komutu bekler ya da bu hatayı basar. Ne zamanki DML kilidi bırakılır ve v$locked_object üzerinde gözükmez, o zaman gelen ALTER TABLE DDL komutu işleme alınır.

DDL_LOCK_TIMEOUT parametresi varsayılan olarak 0'dır (saniye) ve DML lock alınmış bir tabloya DDL gönderdiğimiz zaman hemen ORA-00054 hatası basılır. DDL_LOCK_TIMEOUT parametresi 10 saniye olsaydı DDL operasyonunu yapmak isteyen session'a 10 saniye süre verilecekti ve bu sürede diğer session'dan (DML kilidi almış olan) bir commit ya da rollback gelmediğinde ORA-00054 10 saniye sonra ekrana basılacaktı.

DDL_LOCK_TIMEOUT'un azami parametresi 1.000.000 saniye olabiliyor. Uygulamanızın çalışma mekanizmasına göre bu parametre ile oynamanız faydalı da olabilir zararlıda.

İyi çalışmalar.

Ogan

20 Ekim 2011 Perşembe

Stratejik Karar Alma ve Dış Çevre

Stratejik Karar Alma ve Dış Çevre
Teknolojik devrimlerin yaşandığı, ekonomik çalkantıların tüm dünyanın mali dengesini bozduğu, sosyal ve politik açıdan geleceği belirsiz ülkelerin bulunduğu günümüz dünyasında stratejik karar almak ve değişimi yönetmek oldukça zorlaşmıştır. Stratejik karar alma sürecini desteklemek için belirli analizler yapılmaktadır ve firmalar, dış çevreleriyle olan ilişkilerini kontrol altında tutmaya çalışmaktadırlar.

Günümüzde firmalar, politik, ekonomik, sosyal ve teknolojik gelişmelerin büyük bir ivmeyle değiştiği, çok kısa süre sonrasının bile net olarak öngörülemediği değişimlerin bulunduğu bir ortamın ve rekabetin içinde bulunmaktadırlar. Sürdürülebilir rekabet avantajını ellerinden bırakmak istemeyen ya da ele geçirmek isteyen firmalar bu dört alandaki değişimlerden organizasyonlarını korumak ve stratejilerini geliştirmek için çalışmaktadırlar.

Dış çevre faktörlerinden özellikle teknolojideki çığır açan yenilikler birçok firmanın stratejik karar almasında önemli rol oynamaktadır. Müşterilerin sürekli değişen talepleri, yenilik arayışları teknolojinin daha hızlı değişmesine ve gelişmesine sebep olmuştur. Bu devrimleri takip etmek isteyen firmaların stratejik karar alma fonksiyonları da aynı hızda çalışmadığı ve karar alamadığı takdirde rekabet avantajının kaybolacağı ve direkt olarak şirketi etkileyebileceği bilinmektedir. Örneğin bir uzakdoğu firması bundan çok değil, yalnız 3 sene önce dünyanın en iyi plazma televizyonlarını üretmekteyken ve pazar payında lider konumdayken şimdi pazardan tamamen çekilmiş ve üretimi durdurmuş durumdadır. Bunun arkasındaki sebep ise plazma televizyonların yerine üretilmeye başlanan LCD ve LED teknolojisi televizyonlardır. Şirket stratejik yönetimini ve kararlarını bu doğrultudaki teknolojik gelişmeye paralel sürdürmediği için rakip firmaların yenilikleri (inovasyon) karşısında mağlup olmuş, sürdürülebilir olan rekabet avantajını başka bir firmaya devretmek zorunda kalmıştır. Bu açıdan baktığımızda bir dış çevre faktörü olan teknolojik gelişmelerin ne kadar önemli olduğunu anlayabiliriz.

Bir diğer önemli dış çevre faktörü ise özellikle orta doğuda gelişen politik olaylardır. Birçok şirket yaşanan olaylardan negatif olarak etkilenmiş ve stratejilerini değiştirmek durumunda kalmıştır. Politik belirsizlik ve ülkelerin yatırımlarını bu belirsizlik doğrultusunda azaltmaları, orta doğudaki ülkelere yatırım yapmakta olan firmalar için çok ciddi bir tehdit ve dış çevre faktörüdür. Son yıllarda yaşadığımız ekonomik belirsizlik ortamları yalnızca krizin bulunduğu ülkeyi değil bütün dünyayı etkilemektedir. Bunun başlıca nedeni ticaretin ve teknolojinin küreselleşmiş olmasıdır. Stratejik karar alma sürecinde ticaret yapılan ülke veya ülkelerin ekonomik durumları da göz önünde bulundurulmalıdır.

Dünyanın küreselleşmesi, ticaret ve ekonomik faaliyetlerin kıtaları aşması ve diğer bütün dış çevre faktörlerinin tetiklenmesinin bir numaralı kaynağı teknoloji ve teknolojik gelişmelerdir. Mikro düzeyde düşünüldüğünde daha kolay seyahat etmek, yurtdışındaki kontaktlara ulaşabilmek, yurtdışı ticari girişimlerde bulunmak çok daha kolaylaşmıştır. Bu bağlamda stratejik karar alma sürecindeki en büyük dış çevre faktörü teknolojidir.

Oracle Akademi - "Are You Job Ready Roadshow"

Merhaba,

İş hayatına ne kadar hazırsınız? sorusuyla yola çıktığımız Oracle Akademi etkinliklerini başlatıyoruz.

Oracle Akademi etkinlikleri artık Üniversitenizde. Bütün etkinlikler LinkedIn üzerinden paylaşılacaktır. En yakın etkinlikler ve etkinlik yerleri için aşağıdaki bağlantılara tıklayınız;

Oracle Academy ''Are You Job Ready'' Roadshow @ Istanbul University

Oracle Academy ''Are You Job Ready'' Roadshow @ Şişli Teknik ve Endüstri Meslek Lisesi

Oracle Academy ''Are You Job Ready'' Roadshow @ Suleyman Demirel Universitesi

Görüşmek üzere.

Ogan

6 Ekim 2011 Perşembe

15 Ekim 2011 Bilgisayar Mühendisleri Odası Çalıştayı

Selamlar,

Meslek örgütümüz Bilgisayar Mühendisleri Odasını birlikte kurmak için;

http://events.linkedin.com/Bilgisayar-Muhendisleri-Odasi-Calistayi/pub/815722
http://www.bmo.org.tr/

Katılabilecek herkesin katılımını bekliyoruz. Etkinlik Ankara Milli Kütüphanede gerçekleştirilecektir.

İyi çalışmalar.

Ogan

29 Eylül 2011 Perşembe

ThinkQuest Yarışması

Selamlar,

Oracle Eğitim Vakfı'nın (OEV) sponsorluğunu üstlendiği “ThinkQuest” Yarışması 2012, dünya çapında öğrencilere açıldı!!! Bir çok ödülün yer aldığı yarışmada, öğrenciler uluslararası platformda yeteneklerini test ederken, aynı zamanda 21. yüzyıl'ın vazgeçilmezleri olan teknoloji, iletişim ve eleştirel düşünme becerilerini geliştirip gelecek kariyerleri için gerekli bilgi ve deneyimi kazanıyorlar...

Yarışma resmi web sitesi:
http://www.thinkquest.org/competition

ThinkQuest Uygulama Geliştrime Kategorisi Açıklamaları: http://www.thinkquest.org/competition/application_development/

ThinkQuest Yarismasi 2012
Java
Javascript
PHP
PL/SQL
C#
Flash
Ruby
…ve çok daha fazlasi
Uygulama Gelistirme Kategorisi

Yeteneklerinizi gösterin ve dünya sampiyonu olun
Probleminizi çözen interaktif bir uygulama veya oyun yaratarak programlama becerileriniz ve beyin gücünüzü gösterin. Heyecan verici ödüller kazanin ve hayatinizda elinize bir kez geçecek olan San Francisco

ThinkQuest Live etkinligine katilma firsatini yakalayin. Yarismaya katilarak elestirel düsünme, iletisim ve teknoloji becerilerinizi hem uygulayin, hem de gelistirin. Yarismaya hemen kayit olun ve günümüz rekabetçi is ortamina atilirken sizi farkli kilacak bilgi ve deneyimi kazanmaya baslayin.
Yeteneklerinizi test edin
Sizin için önemli olan bir problemi arastirin
Yaratici, yenilikçi bir çözüm gelistirin
Etkileyici bir uygulama veya oyun yaratin
Projenizin milyonlarca insanin yasam kalitesini arttirabilecegini unutmayin.

Üniversite ve gelecek kariyeriniz için gerekli bilgi ve deneyimi kazanin

Uluslararasi platformda mükemmelliginizi gösterin
Kazananlar ThinkQuest Live etkinligine katiliyor:

Dizüstü Bilgisayar ve baska ödüller kazanin
Yazilim mimarlari, gelistiriciler ve kullanim kolayligi uzmanlarindan yüz yüze rehberlik alin
42,000 Uluslararasi profesyonel ile Oracle OpenWorld deneyimini yasayin
Üst düzey yöneticiler ve uzmanlar ile birlikte kirmizi hali galasinda birlikte olma heyecanini yasayin

Egitici seminerlere katilin ve San Francisco’da eglenceli yerleri ziyaret edin
Ülkenizi onurla temsil edin

Dünyanin dört bir yanindan gelen katilimcilar ile dostluk kurun

Yas Kategorileri

18 - 22, 17 ve alti. Baslangiç yapabilmeniz için çok sayida kaynagimiz mevcut. Web sitemizi ziyaret ederek yarisma proje örnekleri ve yazilim indirme baglantilarina hemen göz atin.

“ThinkQuest Yarismasini kazanmam bana kesinlikle üstünlük sagladi ve mezun olduktan hemen sonra Yazilim Mühendisi olarak is bulmama yardimci oldu.”

Shakeeb, Eski ThinkQuest Sampiyonu
Son Katilim tarihi: 25 Nisan 2012
Daha fazla bilgi
http://www.thinkquest.org/competition
Katilim Sertifikasi

Yarismaya kayit olup projelerini gönderen ögrenciler, katilim sertifikasi almaya hak kazanacaktir.

Olasi Kariyer Firsatlari

Yazilim Gelistirme
Bilgisayar Mühendisligi
Veritabani Yönetimi
Ag/Güvenlik Yönetimi
BT Destek
Web Sitesi Tasarimi
Oyun Tasarimi
Etkilesim Tasarimi
Girisimcilik
Ve çok daha fazlasi…

Staj

Derecelendirmede ilk %10 a giren 18 yas ve üstü ögrenciler Oracle Egitim Vakfi’nda staj yapmak için basvuru hakkina sahip olacaktir. ThinkQuest, Oracle Egitim Vakfi tarafindan desteklenen kar amaci gütmeyen ve kamu yararina hizmet veren ücretsiz bir programdir. Uluslararasi ThinkQuest yarismasinin resmi dili Ingilizcedir. Oracle Egitim Vakfi tarafindan yapilan her türlü iletisim Ingilizce olacaktir. Resmi kurallar ve diger bütün dökümanlar sadece Ingilizce dilinde mevcuttur.

İyi çalışmalar.

Ogan

15 Eylül 2011 Perşembe

Oracle Veritabanı Yönetimi ve Türkçe Paylaşımların Önemi

Merhaba Arkadaşlar,

Şimdi yeniden baktımda, Ocak 2008'den bu yana günlüğümde teknik makaleler paylaşıyormuşum. 2008 yılında 25, 2009 yılında 16, 2010 yılında 53 ve 2011 yılı 15 Eylül itibariyle 50 adet makale girişinde bulunmuşum. Yalnız 2011 yılında her ay en az 1 tane makale girişinde bulunabilmişim. Aslında iş, hayat ve yüksek lisansın bir arada olduğu yoğun bir dönemde kendime göre iyi bir iş çıkardığımı düşünüyorum. Yine umuyorum ki bu yazdığım "Türkçe" yazıların insanlara faydası oluyordur.

Bütün dünyada olduğu gibi ülkemizde de veritabanı yönetimi konusunda kalifiye eleman açığı bulunmaktadır. Bu açığın sebeplerinin başında veritabanı yönetiminin gerçekten zor ve riskli bir iş olması gelmektedir. Maddi (duygusal) açıdan baktığınızda da bir veritabanı yöneticisinin sektördeki başka uzmanlıklara göre daha iyi şartlarda çalıştığını da biliyoruz. Yurtdışında yapılan araştırmalara göre bilişim teknolojileri sektöründe en çok aranan ve kazanan kişiler de veritabanı yöneticileri.  Bir veritabanı yöneticisinin geçmiş tecrübelerine ek olarak OCA, OCP, OCM veya OCE gibi sertifikaları da varsa piyasadaki değeri artmaktadır.

Ülkemizde ne kadar sertifikalı veritabanı yöneticisi var bilemiyorum ancak Oracle ACE ödülüne sahip toplam 6 kişi bulunmaktadır. Bu kişileri görmek için tıklayınız. Hüsnü Şensoy ilk Oracle ACE Director ödülünü alan kişiyken ilk Oracle ACE olan arkadaşımız ise Hasan Tonguç Yılmaz'dır. En son yine Turkcell'den Ferhat Şengönül bu ödüle layık görülmüştür.

Bu bilgileri verdim çünkü bir konuya doğru ilerlemek istiyorum. Ben ve benim gibi paylaşımda bulunan, ödüller alan, etkinliklerde konuşan ve sertifika sahibi arkadaşlarım, Oracle teknolojilerinin ve veritabanı yönetiminin Türkiye'deki simgeleri olmaya devam etmektedirler. Bizim en büyük problemimiz her ne kadar ACE ve sertifikalı veritabanı yöneticisi sayısı artsada paylaşımların eksik olmasıdır. Bir grup arkadaş (genelde TROUG üyeleri) sürekli teknik paylaşımlarda ve etkinlik organizasyonlarında bulunmaktadırlar. Ancak ben istiyorum ki bu tarz etkinliklerde (örneğin TROUG günleri gibi) yine TROUG üyeleri değil de aramızda hiç görmediğimiz ama veritabanı yönetimi konusunda çalışan arkadaşlarımızın olması.

TROUG üyeleri ve paylaşımda bulunan arkadaşlarımızın çabalarıyla Dünya'nın gözünde Türkiye'nin, Oracle veritabanı yönetimi ve paylaşımı konusundaki pozisyonunu değiştirmeye başladık. Şimdi, eskiye göre çok daha iyi noktalardayız.

Oracle ACE ödülleri konusunda daha fazla insanın adını görme şansımız ilerleyen aylarda olacaktır. Ancak Oracle Certified Master'lara baktığımız zaman beş kişinin adı geçmektedir. Hepsi de 10g OCM'dir. Türkiye'de henüz 11g OCM sertifikasına sahip bir veritabanı yöneticisi bulunmamaktadır. Bu bağlamda Türkiye'deki OCM sayısının artması yönünde bir eğilim olabilir.

Yazımın başında da bahsettiğim üzere Ocak 2008'den bu yana günlük tutuyorum ve öğrendiğim birçok teknik konuyu bu günlükte makaleye dönüştürüyorum. Bu günlüğü takip eden insanlar arasında eminim birçoğu zaten İngilizce biliyordur. Ancak her ne kadar İngilizce biliyor olsakta insanın kendi ana dilinde okuması ve anlaması farklı olmaktadır. Benim için önemli olan Türkiye'deki insanların bu yazılardan faydalanmasıdır. Zaten internette bir sürü İngilizce kaynak bulunmaktadır. Bana göre önemli olan Türkçe kaynak sayısını arttırmaktır.

Malcolm Gladwell'in "Outliers" isimli kitabından bir alıntıyla devam etmek istiyorum. Bu kitapta 10.000 saat kuralından bahsediliyor. Teoriye göre bir uzmanlık alanında 10.000 saati deviren kişilerin anca bu kadar zaman harcadıktan sonra "gerçek" uzman olabileceği ifade ediliyor. Bu doğrultuda bir Oracle veritabanı yöneticisi 10.000 saati devirecek işlerini, genelde iş ortamında yapmaktadır. Peki iş ortamı dışında, sizin hiç kendi bilgisayarınıza bir sanal makine kurup, yeni özellikleri denediğiniz veya veritabanındaki kontrol dosyalarını silip, RMAN'den geri almaya çalıştığınız olmadı mı? Cevabınız olduysa neden bunları bir günlük haline getirip, paylaşımda bulunmadınız? Cevabınızı duyar gibi "vakit". Tamam, birçoğumuzun vakti yok ama bunu yaparak sadece diğer insanların bir şeyler öğrenmesine vesile olmuyorsunuz. Aynı zamanda kendi bilginizi ve el reflekslerinizi de geliştirmiş oluyorsunuz. Mesela birçoğumuz TOAD, SQL Developer ya da Enterprise Manager gibi Oracle araçları kullanıyor. Bu araçlar ne yapıyor? 5 saniyede partitioned tablo oluşturuyor, bizim için yedek alıyor, yedekten dönüyor. Hatta yedekten dönerken hangi datafile'ın eksik olduğunu bile söyler hale geldi! Peki bize ne oluyor? Bildiklerimiz eskiyor. Arka planda neler olduğunu unutuyoruz. Unutmamak istiyorsanız yapabileceğiniz en iyi şey bir günlük tutmak ve bu bilgileri paylaşmaktır. Bilgi paylaşımını bir yardım olarak düşünün. Bugün okuyan arkadaşınızın ihtiyacı varken, yarın sizin olabilir. Birbirimize destek olalım ve Türkiye'deki Oracle topluluğunun ve veritabanı yöneticisi sayısının artmasına katkıda bulunalım. Bu arada 10.000 saat kuralı ile ilgili yorumlarınızı alabilirim, bana oldukça mantıklı geldi :)

Son not olarak (gerçi twitter'da paylaşmıştım ama burada hiç paylaşmadım) 15-16 Kasım 2011 tarihlerinde İstanbul'da; Oracle Database 11g Certified Master sınavına giriyor olacağım. Umarım başarılı olurum. Ben kariyerimde ilk kez bir OCM sınavının Türkiye'de gerçekleştirileceğini görüyorum. Bu bağlamda kaçırmak istemeyen arkadaşlarımıza duyurulur. İlgili haber için tıklayınız. Sınava katılacak bütün Türk veritabanı yöneticisi arkadaşlarıma şimdiden başarılar dilerim.

Görüşmek üzere.

Ogan

Oracle Veritabanı 11g - Case Sensitive Şifreleme

Oracle Veritabanı 11g - Case Sensitive Şifreleme

Oracle veritabanı 11g versiyonu ile birlikte gelen case sensitive şifre özelliği hakkında biraz konuşalım. Bildiğiniz gibi 11g versiyonundan önceki versiyonlarda kullanıcı şifrelerinin büyük, küçük ya da karışık düzenle olmasının bir anlamı yoktu. 11g versiyonu ile birlikte bu değişti. Bir örnek;

SQL> show parameter sec_case_sensitive_logon

NAME                                            TYPE                      VALUE
----------------------------------------------------------------------------
sec_case_sensitive_logon              boolean                     TRUE

Veritabanının kurulmasıyla birlikte varsayılan olarak TRUE gelen bu değeri FALSE yapıp case sensitive bilgisini devre dışı bırakabilirsiniz.

SQL> alter system set sec_case_sensitive_logon = FALSE scope = memory;

System altered.

SQL> conn hr/HR@orcl
Connected.
SQL> conn hr/hR@orcl
Connected.
SQL> conn hr/hr@orcl
Connected.
SQL> conn / as sysdba
Connected.
SQL> alter system set sec_case_sensitive_logon = TRUE scope = memory;

System altered.

SQL> conn hr/HR@orcl
ERROR:
ORA-01017: invalid username/password; logon denied


Warning: You are no longer connected to ORACLE.
SQL> conn hr/hr@orcl
Connected.

Sys şifrelerini de değiştirebilmek ve bu şekilde yönetmek mümkün. Bunun için password file'a eklenen "ignorecase" parametresinden yardım alalım ve password file'da da değişikliği geçerli kılalım.

[oracle@db112 dbs]$ orapwd file=orapworcl password=oracle ignorecase=Y force=Y entries=5;
[oracle@db112 dbs]$ sqlplus sys/ORAcle@orcl as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 15 00:15:05 2011

Copyright (c) 1982, 2009, Oracle. All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL> show parameter sec_case_sensitive_logon

NAME                                                TYPE                  VALUE
----------------------------------------------------------------------------
sec_case_sensitive_logon                   boolean                TRUE

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
[oracle@db112 dbs]$ orapwd file=orapworcl password=oracle ignorecase=Y force=Y entries=5;
[oracle@db112 dbs]$ sqlplus sys/ORAcle@orcl as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 15 00:15:05 2011

Copyright (c) 1982, 2009, Oracle. All rights reserved.

ERROR:
ORA-01017: invalid username/password; logon denied


Enter user-name: sys as sysdba
Enter password: oracle

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL>

İyi çalışmalar.

Ogan

13 Eylül 2011 Salı

16.09.2011 CTIS Bölüm Tanıtımı

Merhaba,

Bu Cuma (16.09.2011) tarihinde 09:00 - 12:00 saatleri arasında CTIS bölümünün tanıtımı, DB01 sınıfında gerçekleştirilecektir. Tanıtımın ilgili dokümanı için tıklayınız.

İlgilenen kişilerin katılmasının faydalı olacağına düşünüyorum. Bölüm hakkında detaylı bilgi verilecek, CTIS hakkında sıklıkla sorulan ve akılda kalan sorular yanıtlanacaktır. Bölümün tanıtımında ben de olacağım. 

İyi çalışmalar.

Ogan

16.09.2011 - Güncelleme

CTIS bölüm tanıtımı GE100 etkinliğine katılan yeni öğrencilerimiz için, bölüm hocalarımız tarafından gerçekleştirilmiştir. Katılan arkadaşlarımıza teşekkür ederim ve bütün yeni öğrencilere de başarılar dilerim. Dilerim her şey gönlünüzce olur.

8 Eylül 2011 Perşembe

Materialized View

Materialized View

Bugüne kadar yazdığım makaleleri inceledim ve materialized view'larla ilgili bir şey yazmadığımı fark ettim. Yine eminim ki internet üzerinde materialized view'larla ilgili aramalar oldukça fazla yapılmakta.

Materialized view da diğer bir veritabanı objesi olan view gibidir ve objedir. View'lar bir pointer'dır ve birlikte yaratıldığı sorguya gelen SELECT ifadesini ya da kimi zaman DELETE ifadesini yönlendirir (DELETE'in koşulları var elbet). Materialized view'lar da bir pointer'dır ama view'lar gibi bizim tanımladığımız sorguya point etmezler. Onların yönlendiği yer bizim verdiğimiz sorgudan oluşan bir alandır. Aslında başka bir obje olan tablolar gibi düşünebilirsiniz. View'lar sadece data dictionary'de yer kaplarken, materialized view'lar hem tanım olarak data dictionary'de yer kaplar hem de fiziksel olarak. Bir örnek vermem gerekirse;

[oracle@db112 datapump]$ sqlplus scott/tiger@orcl

SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 7 13:45:50 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> create table emp_new as select * from emp;

Table created.

SQL> insert into emp_new select * from emp_new;

14 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from emp_new;

  COUNT(*)
----------
        28

SQL> set serveroutput on;
SQL> declare
  2  no_rows NUMBER;
  3  mv_size NUMBER;
  4  begin
  5  DBMS_MVIEW.ESTIMATE_MVIEW_SIZE('MV_OGAN',
  6  'select * from scott.emp_new', no_rows, mv_size);
  7  dbms_output.put_line('Satir Sayisi : ' || no_rows);
  8  dbms_output.put_line('MV Boyutu : ' || mv_size);
  9  end;
 10  /
Satir Sayisi : 28
MV Boyutu : 3808


PL/SQL procedure successfully completed.

Yukarıdaki gibi bir materialized view yaratsaydım satır sayısı 28, boyutu ise 3808 olacaktı (bu değer byte'tır). DBMS_MVIEW.ESTIMATE_MVIEW_SIZE prosedürünün sentaksı ise;

DBMS_MVIEW.ESTIMATE_MVIEW_SIZE (
statement_id IN VARCHAR2,
select_clause IN VARCHAR2,
num_rows OUT NUMBER,
num_size OUT NUMBER);

Daha önce yarattığımız bir tabloyu da materialized view'ın içeriği olarak yaratabiliriz.

SQL> CREATE MATERIALIZED VIEW EMP_NEW
   2  ON PREBUILT TABLE
   3  REFRESH FORCE
   4  ENABLE QUERY REWRITE
   5  AS
   6  SELECT * FROM SCOTT.EMP;

Materialized view created.

SQL> select object_name, object_id, object_type
   2  from user_objects
   3  where object_name = 'EMP_NEW';

OBJECT_NAME       OBJECT_ID      OBJECT_TYPE
EMP_NEW                    78479                  TABLE
EMP_NEW                    78480        MATERIALIZED VIEW

Bir materialized view yukarıdaki şekilde yaratılıyor ama benim fazladan yaptığım iş bunu bir öncül tablodan yaratmak oldu. Materialized view prebuilt bir tablodan yalnızca yapısını alıyor, bir örnek;

SQL> drop table emp_new purge;

Table dropped.

SQL> create table emp_new
   2  as
   3  select * from emp;

Table created.

SQL> insert into emp_new
   2  select * from emp_new;

14 rows created.

SQL> /

28 rows created.

SQL> /

56 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from emp_new;

COUNT(*)
------------
            112

SQL> select coun(*) from emp;

COUNT(*)
------------
              14

SQL> CREATE MATERIALIZED VIEW EMP_NEW
   2  on prebuilt table
   3  refresh force
   4  enable query rewrite
   5  as
   6  select * from emp;

Materialized view created.

SQL> select count(*) from emp_new;

COUNT(*)
------------
            112

SQL> drop table emp_new;
drop table emp_new
                *
ERROR at line 1:
ORA-12083: must use DROP MATERIALIZED VIEW to drop "SCOTT"."EMP_NEW"

SQL> drop materialized view emp_new;

Materialized view dropped.

SQL> select count(*) from emp_new;

COUNT(*)
------------
            112

SQL> drop table emp_new purge;

Table dropped.

Bir materialized view yaratabilmek için view ile aynı şartlarda olmalıyız. Yani elimizde sadece bir SELECT cümlesi olması yetiyor (CREATE MATERIALIZED VIEW hakkınızın da olması gerekiyor tabiiki).

SQL> CREATE MATERIALIZED VIEW OGAN_MV
   2  REFRESH FORCE
   3  ENABLE QUERY REWRITE
   4  AS
   5  SELECT * FROM EMP;

Materialized view created.

Şimdiye kadar size iki tip materialized view gösterdim. Bir tanesi prebuilt table üzerinde yarattığımız, diğer ise sanki bir view yaratırmış gibi yaratıp, yalnızca bir sorgu gönderdiğimiz materialized view'dı. Peki bu ikisi arasında nasıl bir fark var? Prebuilt olduğu zaman ne oluyor, olmadığı zaman ne oluyor? Sıradaki örnekte bunu göreceğiz, ardından çıktının ne olduğunu açıklayacağım.

SQL> create table emp_new
  2  as
  3  select * from emp;

Table created.

SQL> insert into emp_new
  2  select * from emp_new;

14 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from emp;

  COUNT(*)
----------
        14

SQL> select count(*) from emp_new;

  COUNT(*)
----------
        28

SQL> create materialized view emp_new
  2  on prebuilt table
  3  refresh force
  4  enable query rewrite
  5  as
  6  select * from emp;

Materialized view created.

SQL> create materialized view ogan_mv
  2  refresh force
  3  enable query rewrite
  4  as
  5  select * from emp;

Materialized view created.

SQL> select substr(mview_name,1,30) mviewname, staleness
  2  from user_mviews
  3  where mview_name in ('emp_new','ogan_mv');

no rows selected

SQL> select substr(mview_name,1,30) mviewname, staleness
  2  from user_mviews
  3  where mview_name in ('EMP_NEW','OGAN_MV');

MVIEWNAME                      STALENESS
------------------------------ -------------------
EMP_NEW                        UNKNOWN
OGAN_MV                        FRESH

EMP_NEW bir tabloyu referans aldığı için materialized view içeriğinin garantisini Oracle veremedi ve staleness alanına UNKNOWN (bilinmeyen) yazdı. Halbuki ogan_mv objesini direkt olarak tablodan ve o anki haliyle oluşturduğumuz için FRESH (taze) olarak gösteriyor.

Materialized view'ların REFRESH özelliğini bu örneklerde FORCE olarak gösterdim. FORCE olduğu durumda gördüğümüzü gösteriyorum;

SQL> insert into emp(empno)
   2  values(9999);

1 row created.

SQL> commit;

Commit complete.

SQL> select count(*) from emp;

COUNT(*)
------------
              15

SQL> select count(*) from ogan_mv;

COUNT(*)
------------
              14

Burada gördüğünüz gibi "select * from emp" olarak yarattığımız ogan_mv hala eski haliyle duruyor.

SQL> exec dbms_mview.refresh(list=> 'OGAN_MV');

PL/SQL procedure successfully completed.

SQL> select count(*) from ogan_mv;

COUNT(*)
------------
              15

DBMS_MVIEW paketindeki REFRESH prosedürü ile materialized view'a son halini veriyoruz. Peki başka ne tür refresh özelliği var? Bir diğeri de FAST refresh özelliğidir ve materialized view'ların çok daha hızlı refresh olmasını sağlar. REFRESH FORCE olarak yaratırsak, bir materialized view'ı yeniden oluştururken içerisindeki sorgunun tamamı üzerinden oluşturur. REFRESH FAST dersek, bir materialized view LOG üzerindeki değişiklikleri takip ederek materialized view'ı refresh eder (yeniden günceller). Bir örnek;

SQL> create materialized view log on emp;

Materialized view log created.

SQL> create materialized view ogan_mv_emp
   2  refresh fast
   3  enable query rewrite
   4  as
   5  select * from emp;

Materialized view created.

SQL> select count(*) from ogan_mv_emp;

COUNT(*)
------------
              15

SQL> insert into emp(empno)
   2  values(1919);

1 row inserted.

SQL> commit;

Commit complete.

SQL> select count(*) from emp;

COUNT(*)
------------
              16

SQL> select count(*) from ogan_mv_emp;

COUNT(*)
------------
              15

SQL> EXEC DBMS_MVIEW.REFRESH('OGAN_MV_EMP');

PL/SQL procedure successfully completed.

SQL> select count(*) from ogan_mv_emp;

COUNT(*)
------------
              16

Buradaki refresh işlemini materialized view log sayesinde tamamladık ama örneğimiz çok ufak ve değişikliğimiz bir tane olduğu için farkı gözlemlemek biraz zor oldu. Milyonlarca kayıt ve değişiklik içerisinde FORCE ve FAST'ın, materialized view LOG'un farkı da ortaya çıkıyor.

Bu durumda materialized view'ların yeniden oluşturulması gerektiğini anlıyoruz. View'larda da ana tabloya yeni bir sütun eklediğinde yeniden yaratmamız gerekiyordu çünkü biz biliyoruz ki her ne kadar bir view'ı SELECT * FROM X ile yaratsakta data dictionary içerisinde bir view *'ın açılmış halini, yani bütün sütunlarını saklar. Bu da ana tabloya yeni bir sütun eklendiği zaman view'ı güncelleme ihtiyacını doğurur. Materialized view'lar da durum aynı. Bir örnekle devam edelim;

SQL> select substr(mview_name,1,30) mviewname, staleness, compile_state
   2  from user_mviews
   3  where mview_name in ('OGAN_MV_EMP','OGAN_MV','EMP_NEW');

MVIEWNAME                       STALENESS                COMPILE_STATE
------------------------------------------------------------------------------
OGAN_MV                            STALE                          VALID
OGAN_MV_EMP                  STALE                          VALID
EMP_NEW                             STALE                          VALID

Dikkat ederseniz hepsi uygun ve güncel durumda (prebuilt MV olan EMP_NEW bile!!). Şimdi ise sırada bir güncelleme var...

SQL> alter session set nls_date_format='DD/MM/YYYY HH24:MI:SS';

Session altered.

SQL> drop table emp;

Table dropped.

SQL> select substr(mview_name,1,30) mviewname, staleness, compile_state
   2  from user_mviews;

MVIEWNAME                       STALENESS                COMPILE_STATE
------------------------------------------------------------------------------
OGAN_MV                       NEEDS_COMPILE          NEEDS_COMPILE
OGAN_MV_EMP             NEEDS_COMPILE          NEEDS_COMPILE
EMP_NEW                        NEEDS_COMPILE          NEEDS_COMPILE

Materialized view'ın altında bulunan emp tablosunun drop edildiğini Oracle fark etti ve önceden tanımladığımız 3 materialized view da geçersiz konumuna düştü. Hatırlayınız -ki OCA veya OCP sınavında gelen bir sorudur- bir view'ın altında yatan obje drop edildiği zaman view da drop edilmiş olmaz, invalid konuma geçer. Bu durumda view'lar için yeniden yaratmak, materialized view'lar içinse compile etmek gerekmektedir.

SQL> alter materialized view OGAN_MV COMPILE;

Materialized view altered.

SQL> alter materialized view EMP_NEW COMPILE;

Materialized view altered.

SQL> alter materialized view OGAN_MV_EMP COMPILE;

Materialized view altered.


SQL> select substr(mview_name,1,30) mviewname, staleness, compile_state
   2  from user_mviews;


MVIEWNAME                                   STALENESS                            COMPILE_STATE
----------------------------------------------------------------------------------------------
OGAN_MV                             COMPILATION_ERROR              COMPILATION_ERROR                  
OGAN_MV_EMP                   COMPILATION_ERROR              COMPILATION_ERROR
EMP_NEW                              COMPILATION_ERROR              COMPILATION_ERROR

Sizce neden compilation_error yazısını görüyoruz? Çünkü ortalarda bir EMP tablosu yok! :) Hemen geri alalım (bu arada veritabanın recyclebin ve flashback_on YES durumda).

SQL> flashback table emp to before drop;

Flashback complete.

Şu anda materialized view'larımız kullanılamaz durumda.

SQL> alter materialized view OGAN_MV COMPILE;


Materialized view altered.


SQL> alter materialized view EMP_NEW COMPILE;


Materialized view altered.


SQL> alter materialized view OGAN_MV_EMP COMPILE;


Materialized view altered.

SQL> select substr(mview_name,1,30) mviewname, staleness, compile_state
   2  from user_mviews;


MVIEWNAME                                   STALENESS                            COMPILE_STATE
----------------------------------------------------------------------------------------------
OGAN_MV                                        UNUSABLE                                      VALID
OGAN_MV_EMP                              UNUSABLE                                      VALID
EMP_NEW                                         UNUSABLE                                      VALID

Tabloyu çöp kutusundan geri getirdiğimiz için staleness kısmı kullanılamaz hale geldi. Her ne kadar compile_state kısmı valid olsada. Bu durumda materialized view'ı refresh etmemiz gerekiyor.

SQL> exec dbms_mview.refresh('OGAN_MV');

PL/SQL procedure successfully completed.

SQL> exec dbms_mview.refresh('EMP_NEW');

PL/SQL procedure successfully completed.

SQL> exec dbms_mview.refresh('OGAN_MV_EMP');
BEGIN dbms_mview.refresh('OGAN_MV_EMP'); END;

*
ERROR at line 1:
ORA-23413: table "SCOTT"."EMP" does not have a materialized view log
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2558
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2771
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2740
ORA-06512: at line 1

Tabloyu drop ettiğimiz zaman üzerindeki materialized view log da düşürülmüş oldu ve refresh, bu MV için başarısız oldu. Şimdi bir materialized view log yaratmak istersek neler olacak bakalım?

SQL> create materialized view log on emp;

Materialized view log created.

SQL> exec dbms_mview.refresh('OGAN_MV_EMP');
BEGIN dbms_mview.refresh('OGAN_MV_EMP'); END;


*
ERROR at line 1:
ORA-12034: materialized view log on "SCOTT"."EMP" younger than last refresh
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2558
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2771
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2740
ORA-06512: at line 1


Olmadı :) Materialized view'ı baştan yaratmak gerekiyor. Son duruma bakalım mı?


SQL> select substr(mview_name,1,30) mviewname, staleness, compile_state
   2  from user_mviews;


MVIEWNAME                                   STALENESS                            COMPILE_STATE
----------------------------------------------------------------------------------------------
OGAN_MV                                        FRESH                                              VALID

OGAN_MV_EMP                              UNUSABLE                                      VALID
EMP_NEW                                         FRESH                                              VALID

Datawarehousing (Veriambarı) konusu içerisinde yer alan materialized view'ların nasıl oluşturulduğunu ve kullanıldığını görmüş olduk.

İyi çalışmalar dilerim.

Ogan

18 Ağustos 2011 Perşembe

External Table

External Table


Interneti biraz araştırdım ve external table başlığı üzerine Türkçe bir kayıt bulamadım. Varsa da benden daha önce bu konuyla ilgili paylaşımı Türkçe yapan arkadaşıma teşekkür ederim.

Oracle'da bir obje olan tablolardan hariç olarak bir de external table objeleri bulunmaktadır ve Oracle bize bu objenin içindekilere sadece okuma erişimi sağlamaktadır. "External", yani harici olduğu için tahmin edeceğiniz üzere bir external table içerisindeki veriler, veritabanının içinde bulundurulmaz. External table'ı bir nevi aracı gibi düşünebilirsiniz. Peki bu external table neye aracılık yapıyor? Örneğin bir dizinde bulunan 3.5 MB büyüklüğündeki basit bir excel dosyasına aracılık yapıyor olabilir. Harici bir tablo veritabanında fiziksel olarak bulundurulmaz. Bu tablonun içerisindekilere müdahale etme şansınız olmaz, yalnız görüntüleyebilir ya da sorgulayabilirsiniz. Tom Kyte'a göre (bir seminerinde bahsetmişti) bir veritabanına veri yüklemenin en hızlı ve sorunsuz yolu external table aracılığı ile yüklemekmiş.

Bir harici tablo üzerinde görüntü (view) yaratabilir, sıralayabilir (sorting) ya da başka bir tablo ile birleştirip (join) sorgulayabilir fakat herhangi bir DML operasyonu (insert, delete ya da update) yapamazsınız. Buna ek olarak bir harici tabloya indeks de tanımlayamazsınız. External table'lar data pump ile de kullanılabilir ve bir veri ambarı sisteminde ETL operasyonlarına dahil edilebilir. (E=Extract T=Transform L=Load). Harici tabloları yaratmak için IOT'lere benzer bir yöntem kullanıyoruz (Index Organized Table). Yani, ORGANIZATION EXTERNAL sıfatını kullanıyoruz. Bir harici tablo aracılığı ile veri yüklemek istediğimiz zamansa SELECT ifadesindeki veri tipleri, data dictionary'de otomatik olarak tanımlanmaktadır.

Bir Oracle veritabanı external table'lardan veri yüklenmesi ve erişilebilmesi için bize iki tane sürücü tanımlamıştır. Bunlar ORACLE_LOADER ve ORACLE_DATAPUMP'dır. ORACLE_LOADER'ın ilk etapta anlamamış olabilirsiniz ama aslında ORACLE_LOADER = SQL * Loader'dır (sqlldr). Hazır yeri gelmişken daha önce sqlldr ile ilgili yazdığım bir makaleyi paylaşmak istiyorum. Lütfen tıklayınız. ORACLE_DATAPUMP'da ise data pump'ın kabiliyetleri ile yola devam edilir. Her ikisinin ve aynı zamanda external table'ların ortak noktası bir veya duruma göre birden çok dizine sahip olmalarıdır. Oracle'da dizinler (directories) nasıl yaratılır gösterelim ve birkaç örnekle yola devam edelim;


CREATE OR REPLACE DIRECTORY ogan_log_dizin
AS
'/u01/ogan/log';


CREATE OR REPLACE DIRECTORY ogan_veri_dizin
AS
'/u01/ogan/veri';


CREATE OR REPLACE DIRECTORY ogan_bad_dizin
AS
'/u01/ogan/bad';

Dizinlerimizi yarattık. Bu dizinleri Oracle veritabanına göstermeden external table'lara geçerseniz hata alırsınız. Her ne kadar yüklemek istediğimiz veri bir excel'de duruyor ve bu excel de fiziksel olarak ilgili dizinde duruyor olsa da Oracle'da directory yaratmazsanız Oracle o excel'e erişemiyor (external table aracılığı ile). Şimdi, dizini kullanabilmemiz için hak tanımlamamız gerekiyor. Bu arada önemli bir nokta, dizinlere bir kullanıcı sahip olamaz. Dizinler Oracle'ın malıdır ve herhangi bir kullanıcı, şema ile ilişkilendirilemez. Biz sadece istediğimiz kişiye ilgili dizinle ilgili haklar tanımlayabiliriz.


GRANT READ, WRITE ON DIRECTORY
ogan_log_dizin TO ogan;


GRANT READ, WRITE ON DIRECTORY
ogan_veri_dizin TO ogan;

GRANT READ, WRITE ON DIRECTORY
ogan_bad_dizin TO ogan;

Gerekli tanımlamarı yaptıktan sonra elimizdeki excel ya da dat uzantılı dosya içeriğine uyumlu bir external table yaratma işlemiyle işimize devam ediyoruz. Elimizdeki excel örneğine gelince;

Ogan Ozdogan1, 101, ABC, 01.08.2011
Ogan Ozdogan2, 102, ABC, 02.08.2011
Ogan Ozdogan3, 103, ABC, 03.08.2011
Ogan Ozdogan4, 104, ABC, 04.08.2011

Yukarıdaki veri setini bir excel dosyası olarak düşünün ve virgüllerle ayrıldığını varsayalım. @, / ya da . gibi karakterlerle de ayırmış olabilirdik. Şimdi bu verisetine göre bir external table yaratalım;

CREATE TABLE ogan_external_tablo
(
isim varchar2(50),
id number(3),
firma varchar2(10),
ise_baslama date
)
ORGANIZATION EXTERNAL
(
TYPE ORACLE_LOADER
DEFAULT DIRECTORY ogan_veri_dizin
ACCESS PARAMETERS
(
RECORDS DELIMITED BY newline
BADFILE ogan_bad_dizin: 'ogan_veri%a.bad'
LOGFILE ogan_log_dizin: 'ogan_veri%a.log'
FIELDS TERMINATED BY ','
MISSING FIELD VALUES ARE null
(

isim, id, firma, ise baslama char date_format date mask 'DD.MM.YYYY'
)
)
LOCATION 'ogan_veri.csv'
)
PARALLEL
REJECT LIMIT UNLIMITED

Harici tablomuzu yukarıdaki komutla yarattık. Şimdi bu yarattığımız harici tablodan, gerçek tabloya veri girişinde bulunalım;


INSERT INTO ogan_tablo (isim, id, firma, ise_baslama)
SELECT * FROM ogan_external_tablo;

Bir harici tablo üzerinde ALTER komutu koşabilmek mümkün ve bu komutla external table'ın varsayılmış olan özelliklerini değiştirebiliyoruz;

ALTER TABLE ogan_external_tablo
REJECT LIMIT 10;

ALTER TABLE ogan_external_tablo
DEFAULT DIRECTORY ogan_veri_dizin_yeni;

İyi çalışmalar.

Ogan

16 Ağustos 2011 Salı

Flashback Data Archive & Total Recall

Flashback Data Archive & Total Recall

Bu yazımda bir 11g özelliği olan flashback data archive ve bir veritabanı opsiyonu olan total recall'dan bahsedeceğim. Günümüzdeki birçok organizasyon için verinin ne kadar kıymetli olduğunu ifade etmek kelimelerle biraz zor. Veriler hem kıymetli hem de veriler üzerinde yapılan tüm değişiklikler de bir o kadar önemli. Bir tablo içerisindeki verilerin ne yönde değiştiğini, kim tarafından hangi işlemlerin yapıldığının takibi gibi konular ciddi uygulama mantığı ve iş yükü gerektiren uygulamalar olarak karşımıza çıkabilir. Verinin geçmişini takip etmek ve görüntülemek gerçekten çok zahmetli ve komplike bir işlemdir. Organizasyonlar da bu işi yerine getirebilmek için ciddi masrafların altına girmekte ve verinin geçmişini, tarihini tutabilmek için zaman harcamaktadır. Oracle'ın Total Recall veritabanı opsiyonu ile bu değişimleri tutmak basit ve veritabanı tablolarından sorgulamak da geleneksel sorgulama tipleriyle kıyaslandığı zaman sorunsuz olacaktır.

Geleneksel Yaklaşımlar

Geçmişe ait geçmiş verisinin takip edilebilmesi için bir takım geleneksel yaklaşımlar ve yöntemler bulunmaktadır. Bütün bu yöntemler yüksek maliyet, yüksek kompleksite ve performans limitleri ile mücadele etmektedir.

Uygulama Mantığı: Verinin tarihini tutmak ve görüntüleyebilmek için kullanılabilen bir yöntem uygulama seviyesinde yapılan mantıksal değişikliklerdir. İş tanımını, isteklerini ve çözümlerini iyi bilen bir uygulama geliştiricisi için oldukça faydalı olabilir ama uygulamayı daha kompleks ve içinden çıkılmaz bir hale dönüştürebilir. Hatalı geliştirilecek ya da mantıksal sorunlara sahip bir uygulama ile sahip olduğunuz bütün veriyi bozma ihtimaliniz her zaman bulunmaktadır. Günümüz organizasyonlarındaki uygulama mantığını ve kaç tane uygulamaya sahip olduklarını düşünürseniz bu çözümü işleme almak bile ciddi bir zaman ve maliyete neden olacaktır. Buna ek olarak yapılacak testler de gelmektedir.

Veritabanı Tetikleri (Triggers): Başka bir alternatif veri geçmişi tutma seçeneği de veritabanı tetikleridir. İlgili tablolar üzerinde gerekli tetikleri yaratarak her veri değişiminde, değişimin tarihi elimizde bulundurulabilir. Ancak, tetiklerin kullanılması merkezileştirilmiş bir arayüz ile kullanılabilen bir çözüm olmadığı gibi yönetimsel açıdan kontrolü ve testleri oldukça zordur ve zahmetlidir. Buna ek olarak yaratılan her tetikle birlikte tetiklenen işlem veritabanı performansını etkilemektedir.

Redo Log Mining: Belkide en sık kullanılan çözüm redolog'ların mining işleminin yerine getirilmesiyle verinin değişim tarihinin kontrol edilmesi, sorgulanmasıdır. Log mining işlemi için ayrı bir araç, yaratılması gereken işlemler ve monitör edilmesi gereken bir süreç bulunmaktadır.

Yukarıda bahsettiğim ve geleneksel yaklaşımlar olarak kategorize ettiğim çözümlerin hiçbiri düşük maliyetli ya da yüksek performanslı çözümler değildir. Herbiri kendine göre karmaşık ve zaman alan, maliyetli çözümlerdir. İşte bu noktada devreye 9i ile birlikte aramıza katılan "Flashback" teknolojisi ve Total Recall veritabanı opsiyonu girmektedir.

Flashback Data Archive

Flashback Data Archive (FDA) bir Oracle Veritabanı 11g ve Total Recall özelliğidir. Verinin bütün geçmişini takip etmek için düşük maliyetli ve performanslı bir çözümdür. Bütün kompleksite bariyerlerini ortadan kaldırmaktadır. Bir retention period (koruma süresi) dahilinde ilgili tablo üzerinde aktive edilecek FDA sayesinde bütün değişimler takip edilir.

Bir 11gR2 veritabanındaki FDA kullanım alanlarına birkaç örnek vermek gerekirse;

* Herhangi bir çalışan tarafından gerçekleştirilen veri değişiklikleri.
* Information Life Cycle Management (ILM) ile verinin geçmişinin değiştirilmeden saklanabilmesi.
* Koruma politikasının zorlamasıyla 5 yıldan eski olan bütün kayıtların silinmesi.
* Geçmişe yönelik raporlamayla değişimlerin ve ilgili ürünlerin takip edilmesi.
* Yanlış güncellenen ve girilen kayıtların geri alınması ve düzeltilmesi.
* Envanterden silinen ama hiçbir zaman satılmayan aktiflerin takip edilmesi.
* SecureFile dosyaları ile orijinal kayıtlar yok edilse bile bir kopyalarının barındırılması.

FDA kullanımı ve aktivasyonu oldukça basit bir süreçtir. Flashback verisini saklamak için bir tablespace oluşturuyoruz. Yarattığımız tablespace içinde bir flashback data archive tanımlıyoruz ve bu özelliği kullanmak istediğimiz tablolarda aktive ediyoruz, hepsi bu!

FDA'nın Faydaları

Verinin yönetilmesi ve tarihinin saklanması konusunda FDA bize zaman ve maliyet açısından kazanımlar getirmektedir. FDA ile istediğimiz herhangi bir tablo üzerindeki bütün değişimleri hızlı, güvenilir ve düşük maliyet ile saklayabilir, sorgulayabiliriz. Geçmişe ait verileri dilediğimiz kadar saklayabilir, koruyabiliriz. FDA'nın uygulamaya alınması tamamen uygulama bağımsız bir işlemdir.

Flashback Data Archive

FDA aslında mantıksal bir araçtır ve sürekli bahsettiğim gibi verinin geçmişine sahip olmamız için gereken bir yöntemdir. Temelinde başka bir fonksiyonalitesi bulunmamaktadır. Oracle Veritabanı 11g versiyonu ile aramıza katılan bir dictionary objesidir. FDA birden çok tablespace üzerinde işlem yapabilir. Bir veritabanı yöneticisi QUOTA anahtar kelimesini kullanarak ilgili tablespace'lerde kullanımak üzere ne kadar FDA verisi ayrılması gerektiğine karar verebilir. Bir tane FDA politikası seçilebileceği gibi birden çok FDA tanımlaması ile işleri daha da kompleks hale getirebilir ve takip edilen tablo sayısını arttırabilirsiniz. Her FDA'nın bir de RETENTION parametresi bulunmaktadır. Bu parametre ile geçmiş verileri ne kadar süre ile tutmamız gerektiğini belirliyoruz. FDA, RETENTION süresi boyunca geçmişe ait değişikliklerin saklanacağı garanti eder ve bu periyot dışında kalan verilerin silineceğini de ifade eder.

Takip altında alınan her tablo için bir içsel diğer tablo FDA tarafından tanımlanır. Bu tablo tamamen FDA'nın kullanımı ile ilgili olup geçmişi takip edilen tablonun metadata bakımından bir kopyası demektir. Takip edilen tabloya ait bir veya birden çok sütunda yapılan değişikliğin önceki imajı bu replika tabloda barındırılır. UPDATE ve DELETE DML komutları bu tablo üzerinde yeni bir kayıt oluştururken, INSERT operasyonu oluşturmamaktadır. Bunun yerine ilgili satır ana tabloda görünmektedir. Bu içsel takip tablosunun en büyük özelliği partitioned olarak yaratılması ve aynı zamanda sıkıştırılmış olmasıdır (compressed). Bu tablolar üzerinde hiçbir değişiklik kabul edilmemektedir. Bu noktada hemen bir soruyu akıllardan kaldıralım, uygulama ya da kullanıcılar "AS OF" ya da "VERSIONS BETWEEN" özelliklerini kullanarak yine undo uzerinden ilgili tablonun geçmiş verilerini her zaman sorgulayabilirler. Flashback ile ilgili daha detaylı bilgi için günlüğümdeki arşivi biraz kurcalamanız gerekmekte :)

Mimari

Bu yazıyı okuyanlarınızdan birçoğu undo'nun, undo tablespace'in, undo management'ın ne olduğunu biliyor aslında. Tabii bilmeyenler için yine günlüğümde undo ile ilgili açıklayıcı teknik makaleler bulunmakta. Eğer undo'nun bir Oracle veritabanında ne işe yaradığı hakkında hiçbir fikriniz yoksa bu noktadan sonrasını okumaya devam etmeden önce lütfen undo'nun tam olarak ne yaptığını ve ne işe yaradığını okuyunuz. Aksi halde konu askıda kalacaktır ve kafanızda soru işaretleri oluşacaktır.

FDA işte bu undo bilgilerini kullanarak, tıpkı diğer birçok Flashback özelliğinde olduğu gibi çalışmaktadir. Burada mutlaka dikkatinizi çekmiştir, "peki o zaman flashback query ile data archive arasındaki fark nedir?" sorusu. FDA'nın limitleri undo tablespace'in limitleri ile ortak değildir. Undo tablespace'in boyutu ve retention period'u flashback'in diğer özellikleri için (flashback database hariç, onun ayrı bir log'u var) sınırlayıcı niteliktedir. FDA'da böyle bir durum söz konusu değildir! FDA yalnızca undo verilerini kullanır ve bir tablo eğer FDA için seçilmiş ve tanımlanmış ise o tabloya ait bütün undo verileri archival için işaretlenir. Bütün transaction'ların geçmişinin ilgili tablo için tutulduğundan emin olmak için yine ilgili hiçbir undo verisi ezdirilmez, saklanır. Aksi halde zaten tutarlı kelimesini, FDA için kullanamazdık. İşte bütün bu işlemleri yerine getiren arka plan görevinin adı da FBDA'dır.

$ ps -ef | grep fbda

FBDA adını alan ve FDA aktif hale geldiği zaman ortaya çıkan arka plan görevi normalde sürekli uyku halindedir. Sistem tarafından yönetilen aralıklar uyandırılır ve archival olarak işaretlenmiş undo kayıtlarını işlemeye başlar. FBDA arka plan görevi ne zamanki bu işi bitirir ve geçmişi oluşturur, ilgili bütün undo kayıtları yeniden silinebilir konumuna getirilir ve otomatik undo yönetimi tarafından istenilen zamanda ezilir, yerine yenileri yazılır yani silinir. FDA'nın asenkron kullanımı sayesinde sistem üzerinde çok ciddi performans etkileri oluşmaz ve hatta gözardı bile edilebilir.


Çalışma mantığına ait bir şemayı yukarıda paylaşıyorum.

FBDA arka plan görevinin uyku-çalışma süreleri arasında denge içsel ilerleyiş ile kontrol edilmektedir. Transaction'ların yükü ve hızı arttıkça daha sık çalışır, azaldıkça da daha seyrek. Transaction'ların yükü ciddi boyutlara ulaştığı zaman varsayılan olarak her 5 dakikada bir uyanır ve çalışarak archival olarak işaretlenmiş bütün undo verilerini işler ve FDA'yı oluşturur.

Bir Flashback Data Archive Örneği

FDA'nın kullanılabilmesi için önceden tanımlanan işlemler bulunmaktadır. Bunlar;

1) FDA tablespace'leri mutlaka automatic segment space management (ASSM) ile yönetilmelidir. Elle yönetilenleri FDA için kabul edilmemektedir.
2) Automatic undo management mutlaka aktif olmalıdır. Aksi halde FBDA arka plan görevi işlevlerini yerine getiremez.

FDA'yı kullanmak için isterseniz yeni bir tablespace yaratabilir ya da daha önceden var olanını kullanabilirsiniz, burada bir sorun yok. Bu arada Automatic Storage Management (ASM) kullanıyorsanız FDA'nın performansı da artacaktır.

CREATE FLASHBACK ARCHIVE fba1
TABLESPACE tbs1
RETENTION 5 YEAR;

Bu örnekte tbs1 tablespace'i önceden var olan ve ASSM ile yönetilen bir tablespace'ti ve bu tablespace üzerinde fba1 isminde, 5 yıl koruma periyoduna sahip bir FDA oluşturduk. Dikkat ederseniz daha önce bahsettiğim QUOTA bilgisini burada kullanmaktadık. QUOTA argümanını vermezsek varsayılan olarak UNLIMITED olacaktır, yani sınırsız. Tam bu noktada FDA'nın kullanımı için mantıksal bir konteyner tanımlamış ve yaratmış olduk. Zaten tablespace'ler de mantıksal konteyner'lerdir.

CREATE FLASHBACK ARCHIVE fba1
TABLESPACE tbs1
QUOTA 25G
RETENTION 5 YEAR;

Yukarıdaki işlemi yerine getirebilmek için;

1) FLASHBACK ARCHIVE ADMINISTER yetkisine sahip olmalıyız.
2) DBA/USER_FLASHBACK_ARCHIVE sistem görüntülerinin bulunması gerekiyor.
3) DBA/USER_FLASHBACK_ARCHIVE_TS sistem görüntülerinin bulunması gerekiyor.

Bundan sonra tek yapmamız gereken FDA'yı dilediğimiz tablolar üzerinde aktif halee getirmek ve fda1 ismindeki FDA'yı kullanmak!

ALTER TABLE hr.employees
FLASHBACK ARCHIVE fda1;

Bu aşamadan sonra employees tablosundaki bütün veri değişimleri fda1 ile ilişkilendirilen mantıksal konteyner'de 5 yıl boyunca saklanacaktır. Burada dikkat edilmesi gereken konu daha önce bahsettiğim içsel geçmiş tablosunun henüz yaratılmamış olmasıdır. İlk DML operasyonu ile birlikte ilgili içsel geçmiş tablosu yaratılacaktır.

Geçmiş Verinin Sorgulanması

FDA sayesinde AS OF veya VERSIONS BETWEEN kullanarak geçmiş veriyi sorgulayabiliriz. Belirttiğiniz retention period süresince bu komutları, tanımladığınız tablo için dilediğiniz gibi kullanabilirsiniz.

SELECT first_name, last_name, salary
FROM hr.employees
AS OF TIMESTAMP TO_TIMESTAMP('16/08/2009 23:55:00','DD/MM/YYYY HH24:MI:SS')
WHERE employee_id = 100;

Örnekler:

ALTER FLASHBACK ARCHIVE fla1 
SET DEFAULT; --> fla1'i varsayılan FDA olarak tanımladık.


ALTER FLASHBACK ARCHIVE fla1
ADD TABLESPACE tbs3
QUOTA 3G; --> fla1FDA'sına tbs3'ü, 3G kota ile ekledik.

ALTER FLASHBACK ARCHIVE fla1
MODIFY TABLESPACE tbs3
QUOTA 5G; --> tbs3 tablespace'inin FDA kotasını 3'den 5 GB'ye çıkarttık.

ALTER FLASHBACK ARCHIVE fla1
PURGE ALL; --> fla1'in bütün geçmiş verisini sildik.

ALTER FLASHBACK ARCHIVE fla1
PURGE BEFORE SCN 32489234; --> 32489234 SCN'sinden önceki bütün geçmiş verisini sildik.

DROP FLASHBACK ARCHIVE fla1; --> fla1 FDA'sını sildik.

ALTER TABLE hr.employees
NO FLASHBACK ARCHIVE; --> employees tablosundaki FDA'yı kaldırdık.

İyi çalışmalar dilerim.

Ogan

Kaynak

22 Temmuz 2011 Cuma

CTIS 2011 by Erkan Uçar

Selamlar,

Bilkent Üniversitesi Bilgisayar Teknolojisi ve Bilişim Sistemleri (Computer Technology & Information Systems) bölümünün 2011 tanıtımını görmek için tıklayınız. Tanıtım bölüm başkanımız Erkan Uçar tarafından hazırlanmıştır. Güzel olmuş :)

CTIS bölüme ait birçok veriye bu sunum aracılığı ile ulaşabilirsiniz.

İyi çalışmalar.

Ogan

4 Temmuz 2011 Pazartesi

Oracle Open World 2011

Merhabalar,

OOW 2011'de TROUG kurucu üyesi olan ve TROUG Day 2011'de birlikte sunum yaptığımız arkadaşım Emre Baransel Data Guard'ın daha etkili ve farklı kullanımları üzerine bir sunum yapacaktır.

Sunumla ilgili bilgi için tıklayınız.

Emre'nin kendi günlüğündeki yazısı için tıklayınız.

Kendisini bir defa daha tebrik ediyorum ve başarılar diliyorum, gururmuz oldu.

İyi çalışmalar.

Ogan

22 Haziran 2011 Çarşamba

TROUG Day 2011 Sunum Video'ları

Selamlar,

TROUG (Turkish Oracle User Group) ekibinin hazırladığı seminerde konuşmacı olarak sunum yapan arkadaşlarımızın video'ları yayınlanmıştır.

Sunumların video'ları için tıklayınız.

Benim ve Emre Baransel'in yaptığı sunum için tıklayınız.

İyi çalışmalar.

Ogan

21 Haziran 2011 Salı

Oracle Türkiye

Merhabalar,

3 yıllık Ericsson serüvenime 31 Temmuz 2011 Pazar günü son veriyorum.

1 Ağustos 2011 Pazartesi gününden geçerli olmak üzere Oracle Türkiye'de "Senior Sales Consultant" (Kıdemli Satış Danışmanı) olarak göreve başlıyor olacağım.

Bana bugüne kadar Ericsson'da ve işe alım sürecinde Oracle Türkiye bünyesinde destek olan herkese teşekkürü bir borç bilirim.

Yeni görevime başlayacağım günü iple çekiyorum ve umarım hem kendime hem de Oracle Türkiye'ye faydalı olurum.

İyi çalışmalar dilerim.

Ogan

Ankara'da Oracle Seminerine Katılır mısınız?

Merhaba,

Birkaç aydır günlüğümde sürdürdüğüm anketin sonucuna bakalım. "Ankara'da Oracle Seminerine Katılır mısınız?" şeklindeki anket sorusuna 75 evet oyu, 19 da hayır oyu gelmiş. Bu durumda Ankara'da bir Oracle semineri düzenleyeceğiz.

TROUG üyeleri ile bu konuyu görüştükten sonra günlüğüm, FriendFeed ve Twitter üzerinden sonucu sizlerle paylaşıyor olacağım.

İyi çalışmalar.

Ogan

Kurumsal Şirketlerde Stratejik Satış Yönetimi

KURUMSAL ŞİRKETLERDE
STRATEJİK SATIŞ YÖNETİMİ

            Kurumsal şirketlerin oldukça yakından takip ettiği satış departmanlarının üstlendiği rol gün geçtikçe artmaktadır. Ulaşılması neredeyse imkansız ama motivasyonun düşmesine neden olacak kadar uzak olmayan satış hedefleri ve kotaları, ilerleyen teknolojinin sebep olduğu farklı yöntemlere ve teknolojik araçlara, yazılımlara adapte olmak, şirket genel stratejisine uygun kararlar almak ve belkide aralarında en önemlisi olan müşteriyi memnun etmek satış yönetiminin ve satış personelinin en üst düzeyde gerçekleştirmesi gereken görevleri arasındadır.

Satış Gücü ve Eğitimi
            Stratejik satış yönetiminin en alt parçası ama üstlendiği görev ile en üst parçası kadar önemli olan satış personelinin, günümüz küresel şirketlerinde üstlendiği görevler her geçen gün artmaktadır. Satış personelinden yalnızca satış yapması beklenmemekte aynı zamanda belirli sürelerle farklı ürünlerin ya da hizmetlerin öğrenilmesi ve satılması da istenebilmektedir. Bu, kimi şirketlerde ürün bazlıdır kimi şirketlerde de lokasyon veya müşteri odaklıdır. Kurumsal şirketlerin üst düzey stratejik yönetim kararları oldukça karmaşıktır ve birçok faktörden etkilenir. Bunların başında teknoloji ve rakip firmaların sebep olduğu baskı bulunmaktadır fakat sonuçta ana hedef ve değişmeyecek olan strateji, daha çok satmaktır. Bu bağlamda kurumsal şirketler, stratejik satış yönetimine uygun olarak, satış yöneticisi ve personelini eğitmek, onlara daha farklı vasıflar kazandırmak ve bazen de sertifikasyon sahibi yapmak istemektedir. Bu yönleriyle müşteriyi daha kolay ikna edebilir ve satış potansiyellerini yükseltebilirler. Satış personelinin eğitilmesi ya da diğer bir ifade ile geliştirilmesi (empowerment) her ne kadar etkili bir prensip olsa da bir takım dezavantajları olabilmektedir. Bunlar; bağımsız olarak çalışacak ve sorumluluk alabilecek seviyede kişilerin işe alınması, bu kişilerin eğitimlerinin yalnızca satışla ilgili değil aynı zamanda bilgi, yönetim ve kişisel gelişim üzerine de olması ve diğer satış personeline (daha az tecrübeli) daha az promosyon veya teşvik priminin dağıtılmasıdır.
            Kendini geliştirmeye açık ve kurumsal şirket tarafından eğitimlere gönderilen satış personelinin motivasyonunun yüksek tutulması için promosyonlar ya da teşvik primleri verilmektedir. Bazen yaptığı satışlar üzerinden belirli bir yüzde ile nakit ödenen primler, bazen de maddi değeri olan ürün bazında ödüllendirme ile olabilmektedir.


Teşvik Programı
             Teşvik programı belirli bir amacın, davranışların ve aksiyonların daha etkili olarak yerine getirilebilmesi için ortaya çıkmış bir programdır. Bu programlar genel olarak çalışanların motivasyonunun sağlanması için kullanılmaktadır ve satış departmanı üzerinde yoğunlaşır.
         Kurumsal şirketlerin teşvik programını kullanmasındaki en büyük sebep şirket çalışanlarının düşük motivasyonlarının arttırılması, hedeflere ulaşmadaki sorunların ortadan kaldırılması, işten ayrılma oranlarının azaltılması ve yönetime olan beklentilerin yükseltilmesi gelmektedir. Şirketlerde yapılan en büyük hata ise teşvik programlarının detaylı olarak incelenmeden yürürlüğe konulması ve hedeflerindeki kitlenin buna nasıl uyabileceğini tahmin etmemeleri gelmektedir.
          Teşvik programının işleyişinde katılımcıların belirli puanlar toplaması gerekmektedir. Örneğin satış departmanındaki bir satış personeli için bir çıta belirlenir ve bu çıtanın üzerine çıktığı her kademe için kendisine puan verilir. Puanlarının karşılığı olaraksa teşvik programı yönetmeliğine uygun ödüller verilir. Agresif satış örgütlerinde çıtalar ya da kotalar oldukça yüksektir ve çalışanlar bu hedefleri aşabilmek için çabalarlar. Aştıkları durumda da çalışmalarının karşılığı maddi olarak ödenir.
            Satış teşvik planları (Sales Incentive Plan – SIP) genel olarak satışları arttırmakta, satış maliyetlerini azaltmakta, karlılığı arttırmakta, yeni alanlara katılmakta ve kotaları arttırmakta kullanılmaktadır. Satış teşvik planları direkt olarak sonuçları en çok etkileyen teşvik programlarıdır. Satış teşvik planları bir satış personelinin belirli bir sürede (genel olarak bir muhasebe yılı ya da çeyreği) tamamlaması gereken hedefleri içeren bir programdır ve amacı satış personelini motive etmektir. Satış teşvik planları stratejik satış yönetiminin bir parçasıdır ve genel olarak satış takımı bazında belirlenir. Bu doğrultuda satış ekibindeki her satış profesyoneli, takım için belirlenen hedefi tutturmak için çalışacak, motive olacaktır.
           Teşvik programlarında verilen ödüller genel olarak maddi ödüllerdir ve satış profesyoneline nakit olarak ödenmektedir. Ancak araştırmalara göre anket katılımcılarının büyük bir çoğunluğu nakit ödüllerin daha motive edici olduğunu ifade etseler de nakit ödüllerin sağladığı motivasyon sürelerinin düşük olduğu ortaya konmuştur. Bu bağlamda teşvik programlarının nakit ödüller dışında motive edici manevi ödülleri de bulunabilmektedir. “Center of Concept Development”ın yaptığı bir araştırmada nakit ödüllendirmenin çabuk unutulduğu ve motivasyonunun kısa sürdüğü ortaya konulmuştur. Nakit olmayan ödüller ise genel olarak çalışan performansına dayalıdır ve uzun süreli tatmin, motivasyon sağlamaktadır. Buna gösterilebilecek en büyük örnek kurumsal şirketin ofisi içerisindeki duvarlarda paylaşılacak satış personelinin başarı öyküsüdür. Bu, çok ciddi bir teşvik planıdır ve maddi olan teşvik priminden çok daha motive edicidir. Bu ödüller dışında, hediye kartı, elektronik ürünlerin hediye edilmesi, seyahat masraflarının karşılanması veya ilgili personelin tatile gönderilmesi gibi birçok ödül teşvik programı kapsamında personele verilebilir. Manevi ödül olaraksa şirket logosunun bulunduğu ve yapılan üstün hizmeti takdir eden bir yazının içerik olarak sunulduğu tek bir A4 kağıt verilebilir.

Satış Yönetiminin Stratejisi
            Günümüzde birçok kurumsal şirket yalnızca satış departmanındaki satış yöneticisi ya da personelinden satışı sürdürmelerini beklememektedir. Satış departmanının amacı daha çok satmaktır fakat kurumsal şirketler artık bütün personelinden satışa katkıda bulunmasını istemektedir. Bu bağlamda şirket içindeki her birey aynı zamanda bir teknik personel ve satışçı olabilmektedir. Önceleri kurumsal örgütler içerisinde daha merkezi ve dinamik olmayan bir örgüt yapısı bulunmaktaydı. Bu yapıda da çalışanlar yalnızca kendi vazifelerini ve yapmaları gerekenleri yapıyorlardı. Artan rekabet, ilerleyen teknoloji ve telekomünikasyon, kurumsal şirketleri bu yönde bir değişikliğe ve her çalışanın satışa destek olabilmesi için hedefler koymaya yönlendirdi. Şu anda birçok kurumsal şirketin satış stratejileri arasında, satış departmanından olmayan kişilerden gelecek satış katkıları da bulunmaktadır. Buna ek olarak, bu personelin satışa daha çok katkıda bulunması ve görünmeyeni satması için de satış eğitimleri planlanmaktadır.
            Kurumsal şirketlerdeki satış ekibinin, satış sürecini yönetmesi için çeşitli modeller bulunmaktadır. Temel olarak satış gücü yönetim sistemleri olarak adlandırılmaktadırlar. Bu yönetim sistemlerine, zaman, çağrı, fırsat, müşteri, bölge ve satış gücü yönetimi modüllerini ekleyebiliriz. Stratejik satış yönetiminin bir parçası olan satış gücü yönetiminin amacı müşteri ilişkilerini daha etkili olarak yönetmek, hedef ve kotaları belirlemek ve daha agresif bir satış organizasyonunun temellerini atmaktır. Çoğu zaman pazarlama bilgi sistemleri ve müşteri ilişkileri yönetimi modelleri ile de birleştirilebilmektedir. Satış gücü otomasyonunun stratejik avantajları arasında:
1)      Üretimin maksimize edilmesi, satış ekibinin zamanını daha efektif olarak kullanabilmesi ve aynı zamanda satış yöneticisinin de zamanını doğru kullanabilmesi ve bu bağlamda rekabet üstünlüğünün kurumsal şirkete geçmesi.
2)      Sahadaki satış personelinin daha fazla bilgi göndermesi. Tipik olarak satış fırsatları ve öngörülerinin bildirilmesidir. Bu bağlamda kurumsal şirket daha çevik ve bilgi yüklü olacaktır.
3)      Bu sistem müşteri memnuniyetini arttırmaktadır.
            Satış gücü otomasyon sisteminin en büyük dezavantajı birlikçe çalışmasının zor olması, verilerin girişi için daha fazla zamana ihtiyaç olması ve maliyetli olmasıdır. Buna ek olarak diğer yönetim sistemleri ile entegre olması da zordur.

Satış Süreci
            Kurumsal şirketler her noktada daha efektif sonuç elde edebilmek için belirli satış süreçleri izlemektedirler. Şirketler arası ufak farklılıklar gözlemlense de temel olarak süreç aynı yapıda ilerler. Satış süreci bir ürün ya da hizmetin bütün satışı boyunca izlenen süreçtir. Belirli bir satış sürecine sahip olmanın avantajları arasında satıcı ve alıcının risk yönetiminin sağlanması, standart hale getirilmiş bir satış süreci ve ölçeklenebilir kar yaratılması bulunmaktadır. Yapılan birçok araştırmada satış ve proje yönetimi için bir kalıp süreç izleyen şirketlerin, belirli bir süreç izlemeyen şirketlere göre daha üretici ve başarılı olduğu ortaya konulmuştur.
            Satış süreciyle ilgili şirket bazında ufak tefek değişiklikler gözlemlense de genel olarak aşağıdaki gibi bir süreçler bütünü, satış sürecini oluşturmaktadır:
Süreç Tipi:
            Adım 1: Birincil Müşteri Teması
            Adım 2: Satışın Uygunluğunun Kontrol Edilmesi
            Adım 3: Satışın Yaratılması (Sales Lead)
            Adım 4: Gerekli Tanımlamaların Yerine Getirilmesi
            Adım 5: Müşterinin İsteklerinin Net Olarak Anlaşılması
            Adım 6: Teklif Süreci
            Adım 7: Pazarlık Aşaması
            Adım 8: Satışın Kapanması
            Adım 9: Geçmiş Tecrübelerin Paylaşılması ve Yeniden Satılması
        Süreçlerin belirli bir akışla ilerlemesi, satış ekibinin gözünden risklerin minimize edilmesi anlamına da gelmektedir. Buna ek olarak kaynakların da düzgün atanması ve yönetilmesi, satış yöneticisi tarafından sağlanabilmektedir. Formalize edilmiş bir satış süreci ve tanımı daha çok kompleks bir satış yapısına sahip, oldukça fazla kar riski taşımakta olan ve satış danışmanlığını yaklaşımını benimsemiş kurumsal şirketlerde kullanılmaktadır. Bu tipte kurumsal şirketlere örnek olarak IBM, Hewlett-Packard verilebilir.
            Birçok şirket kendi satış sürecini ve akış yapısını oluşturmaktadır ancak satışa hazır olarak bulunan (off the shelf) ürünlerin de satış sürecini kontrol etmek için kullanıldığı görülmektedir.

Müşteri İlişkileri Yönetimi (CRM)
         Stratejik satış yönetiminin bir kurumsal şirket için vazgeçilmezi olan müşteri ilişkileri yönetimi yaygın olarak kullanılan bir müşteri – satış yönetim modülüdür. Teknolojinin de yardımı ile iş süreçlerinin otomasyonunun yapılması, diğer birimlerle senkronize edilmesi ve genel olarak satış süreci ile bütünleşmesi sağlanmaktadır. Ek olaraksa pazarlama, müşteri servisleri ve teknik desteğe kadar uzanmaktadır.
            Müşteri ilişkileri yönetiminin amaçları arasında daha fazla müşteri bulmak ve onları kazanmak, memnun etmek ve memnun edildikleri sürece müşteriyi elde tutmak, pazarlama ve satış maliyetlerini düşürmek gelmektedir. Satış yönetiminin temel hedefleri arasında yer alan müşteri memnuniyeti, maliyetlerin düşürülmesi, daha çok satış yapılması ve kazanılan müşterilerin elde tutulması gelmektedir ve bu bağlamda müşteri ilişkileri yönetimi özellikle satış departmanları için hayati önem taşımaktadır. Müşterilerin olmadığı bir ortamda kurumsal firmaların da yaşayamayacağı ortadadır ve motivasyon cümlesi olarak “maaşlarımızı şirketimiz değil, müşterilerimiz ödemektedir” gelmesi aslında müşteri ilişkileri yönetiminin ne kadar önemli olduğunu ortaya koymaktadır. 

10 Haziran 2011 Cuma

Oracle 11gR1 ve Function Based Index

Selamlar,

Bugün karşılaştığım bir hata ile ilgili yazmak istiyorum. Bir müşterimizin veritabanı versiyonu 11gR1 (11.1.0.7) ve birkaç sorgudaki yavaşlık problemi üzerine SQL tuning ile uğraşıyordum. Sorguların yüklem kısmında (WHERE koşulu ya da predicate) bir string concat işlemi yapıldığını ve index kullanımının partition'lar üzerinde devre dışı kaldığını gözlemledim. Zaman bilgisi ile concat işlemini içeren kolonlarla bir composite index oluşturdum, yani bir function based index. Sorgunun maliyetini yeniden kontrol ettiğim zaman kazanç oldukça tatmin ediciydi ve yarım saate yakın süren ilgili sorgu 2 saniyeye kadar düşmüştü.

Bu optimizasyon çalışmasının ardından üçüncü parti bir ürün aracılığı ile sorguyu denedim. Sonuç gelmeyince nedenini araştırmak üzere alert.log dosyasına baktım ve ORA-7445 ve ORA-600'lerle dolmuş taşmış bir alert.log dosyası gördüm. Bug'ları ve internal error'leri görünce hemen metalink'e baktım şu id'li notu gördüm:


Bug 8682138: PSRC: ORA-7445 [QEAECNT] OR ORA-600 [9999] OCCURS, EXECUTING CERTAIN SQL

Platform HP-UX ve Oracle Veritabanı 11gR1 kullanıyorsa bu şekilde bir hata meydana gelebiliyormuş. 8682138 numaralı Bug'ın en büyük karakteristiği ise function based index'lerin kullanılıyor olmasıymış. Yarattığım function based index'lerin sonuna "compute statistics" eklediğim için CBO, ilgili sorgu için bu index'leri hemen kullanmaya başlamış ve doğru olanı da yapmış olmasına rağmen bu hataları aldım.

SR açılması şart olan bir durum ve function based index'i kaldırdığım zaman performansın eskisi gibi kötü olduğunu gördüm.

İyi çalışmalar.

Ogan

9 Haziran 2011 Perşembe

İstanbul Bilgi Üniversitesi Uzaktan MBA (e-MBA) Programı

Merhabalar,

Geçtiğimiz hafta finallerine girerek ikinci dönemini de geride bıraktığım İstanbul Bilgi Üniversitesi Uzaktan MBA, yani elektronik mba programı hakkında yazı yazma gereği duydum. Bu yazıyı yazmamdaki en büyük sebep internet üzerindeki tartışmalar ve yorumlardır.

Öncelikle uzaktan eğitim programları hakkında bahsetmek istiyorum. Günümüzdeki çağdaş üniversitelerde uzaktan eğitim programlarına verilen önem artmakta ve her seviyede akademik derece çalışmaları yerine getirilmektedir. Ülkemizde daha yaygın olan uzaktan eğitim programı MBA (master of business administration, işletme yönetimi yüksek lisansı) eğitimidir ve yüksek lisans derecesi, ilgili Üniversite tarafından verilmektedir. Aynı şekilde uzaktan eğitimle PhD (doctor of philosophy, doktora) derecesi de verilebilmektedir.

Buraya kadar bir sorun yok lakin uzaktan eğitim almak yer ve zaman bağımlılığını ortadan kaldırdığı için faydalı olduğunu da söyleyebiliriz. Ancak internet'i biraz araştırdığınız zaman ne yazık ki bu programlar hakkında pekte iyi yorumlar göremiyorsunuz. Bu tipte uzaktan eğitimle yüksek lisans veren Üniversite programları "parayla yüksek lisans derecesi satın almak" ya da "askerlikten en az 3 yıl kaçmanın yegane yolu" gibi görülüyor. Şunu net bir şekilde ifade edebilirim ki daha önce de Bilkent Üniversitesi Bilgisayar Teknolojisi ve Bilişim Sistemleri bölümü hakkında yazdıklarım gibi tarafsız yazıyorum ve kimsenin bir etkisinde değilim. Bu bağlamda İstanbul Bilgi Üniversitesi'nin e-MBA programının parayla satın alınan bir yüksek lisans derecesi dağıtmadığını ya da askerlikten kaçabileceğiniz kadar kolay puan dağıtmadığını net bir dille söyleyebilirim. Programın dersleri ve ders içerikleri oldukça zengin ve her hafta düzenli çalışma ile iyi bir bilgi birikimi sağlayarak mezun olabilirsiniz.

Uzaktan eğitim programları teknolojinin de ciddi anlamda gelişmesi ile yaygınlaşma eğilimindedir. Ben bu tarz programları destekliyorum çünkü bugün iş hayatımızda bile evden çalışma imkanı bulabiliyoruz. Neden eğitime devam etme imkanını sağlayamayalım ve gelişmesine katkıda bulunmayalım?

İstanbul Bilgi Üniversitesi e-MBA programına askerden kaçmak ya da para ödeyerek yüksek lisans derecesi alabilmek hedefleri ile başvurmamanızı tavsiye ediyorum çünkü bir şeyler öğrenmeden, ödevlerinizi zamanında ve eksiksiz olarak tamamlamadan ve düzenli bir çalışma olmaksızın mezun olma şansınız yok. Lütfen internet'teki yorumlara itibar etmeden önce iki defa düşünün. Uzaktan eğitim programlarının yüksek lisans derecesinin, sınıfta verilen eğitimlerle alınan yüksek lisans derecesinden bir farkının olmadığı YÖK tarafından onaylanmıştır ve diplomanızda da uzaktan mba gibi bir ibare bulunmayacaktır.

İstanbul Bilgi Üniversitesi MBA programları hakkında daha detaylı bilgi için tıklayınız. Program koordinatörü Yard. Doç. Dr. Metehan Sekban'ın mesajını okumak ve video'larını izlemek için tıklayınız.

İyi çalışmalar.

Ogan
Takip et: @oganozdogan