Ogan Özdoğan - Oracle Günlük

Savunmada Bilişim Konferansı - 7 Şubat 2012 Salı

2012-02-01T17:33:00.000+02:00

Selamlar,

Savunma Sanayii Müsteşarlığı'nın ev sahipliğinde ve Interpro Medya Yayıncılık işbirliğiyle 7 Şubat 2012 Salı günü "Savunmada Bilişim Konferansı" düzenlenecektir. Konferansın amacı; "Savunma Sanayinde Bilişim Teknolojilerinin kullanımını arttırmak ve en yeni teknolojileri, konusunun uzman kişiler tarafından aktarılmasını sağlamak ve sektörel buluşma ve tanışıklık geliştirmek".

Konferansta benim de 15 dakikalık veritabanı güvenliği ile ilgili bir sunumum olacak. Konferansla ilgili detaylı bilgiye, programa ve konuşmacılar listesine aşağıdaki bağlantılardan ulaşabilirsiniz.

SSM Etkinlik Duyurusu

Savunmada Bilişim Konferansı

Savunmada Bilişim Konferansı Programı

Savunmada Bilişim Konferansı Konu Başlıkları

Savunmada Bilişim Konferansı Sponsorları

İyi çalışmalar dilerim.

Ogan

Rekabet ve Rekabet Avantajının Sürdürülebilirliği

2012-01-26T10:52:00.001+02:00

Rekabet ve Rekabet Avantajının Sürdürülebilirliği

Rekabet, 21. yüzyıl ile birlikte neredeyse bütün sektörlerde ciddi boyutlara gelmiştir. Firmalar temel yeteneklerini geliştirebilmek ve rekabette daha üstün olabilmek için yeni formüller geliştirmektedir. Artan teknoloji ve küreselleşme, firmaların yerel değil aynı zamanda küresel boyutlarda operasyona devam etmesi, rekabetin 5 temel güç kuralının (M. Porter) daha da agresifleşmesi, rekabetin şiddetini de arttırmaktadır. Rekabetteki bu şiddete karşı ayakta durmasını başaran firmalar sektörde hayatta kalabilmektedir.

Sürdürülebilir rekabet avantajını eline geçirmiş bir firmanın karşısında çeşitli baskılar bulunmaktadır. Bunlar rakip firmanın baskısı, müşterilerin yeni isteklerine cevap verebilme, teknolojiye ayak uydurabilme, çevre koşullarının analizi ve adaptasyonu ve şirket içi iletişim becerileridir. Bu avantaja sahip firmaların bazıları kendilerini belirli dönemlerde rahat hissedebilir. Genelde monopol bir piyasadayken karşılaşılan bu durum, piyasaya yeni giren hatta girebilecek konumda olan bir firma ile ortamdaki hava değişebilir, sürdürülebilir rekabet avantajına sahip firma üzerinde baskı oluşturabilir. Kimi durumlarda da müşterilerin ve tedarikçilerin pazarlık gücüne bağlı olarak rekabetteki dengeler ve firma stratejileri değişebilmektedir.

İlk bakışta sürdürülebilir rekabet avantajına sahip olabilmek için firmaların sadece temel yeteneğini veya yeteneklerini çok iyi kullanması gerektiği anlaşılabilir. Ancak durum aslında bu kadar basit değil, daha karmaşıktır. Firmalar temel yeteneğine, organizasyonel öğrenme ve güçlendirme (empowerment), sahip olunan teknolojinin yönetimi ve geliştirilmesi, stratejik ve fonksiyonel kararlarda esneklik ve insanların motivasyon faktörlerinin kontrolünün eklenmesi de gerekmektedir. Bütün bu bileşenleri temel yeteneğine entegre edebilen şirketlerin önü açılmıştır ve sürdürülebilir rekabet avantajına ulaşmakta engelleri azaltmışlardır.

Bir firmanın rekabette bulunduğu noktayı algılayabilmesi için öncelikle SWOT analizini çok iyi yapmış olması gerekmektedir. Ardından çevreye kadar ne kadar duyarlı olduğuna da PESTEL analizi ile görmesi gerekmektedir. SWOT ve PESTEL analizlerinden sonra firmanın güçlü, zayıf olduğu noktalar, çevredeki değişimlere verebildiği ya da veremediği tepkiler, etrafındaki çeşitli tehditler ve fırsatlar konuları anlaşılabilmektedir. Bu sayede firma kendisini aynada görebilmekte ve atması gereken stratejik adımları tasarlayabilmektedir. Bu tarz adımları atmadan rekabet üstünlüğü gibi ciddi bir konuyu elde etmesi çok zordur.

Rekabet üstünlüğündeki ürün ve hizmetlerin iyi denetlenmesi gerekmektedir. Ürün veya hizmet hakkındaki stratejilerin belirlenmesi gerekmektedir. Üstünlük bir odaklanma stratejisi ile mi yoksa farkılaştırma ya da maliyet liderliği stratejisi ile mi ele geçirilmelidir? Ürün ve hizmet açısından rekabete baktığımızda her firmanın amacı daha uygun fiyatlara daha kaliteli ürünleri müşterileri sunmakta olabilir, daha da uygun fiyatlara daha az kaliteli ürünleri de. Burada stratejik yönetimin rekabetin hangi noktasında olduğunu biliyor olması gerekiyor.

Rekabet üstünlüğünde önde olunduğunun somut kanıtları arasında hedef müşterilere sunulan ürün veya hizmetin pazardaki payı bulunmaktadır. Pazar payındaki artış firmanın sürdürülebilir rekabet üstünlüğünde bir adım daha öne geçtiğini göstermektedir. Bu, somut bir durum olduğundan aslında öne geçtiği gibi görülmektedir. Ancak bu duruma eklenebilecek soyut ve arkaplanda olan bir takım dinamikler bulunmaktadır. Bunlar arasında şirket çalışanlarının motivasyonu, atılabilecek önemli stratejik adımlar (şirket satın almaları gibi), sosyal sorumluluk projeleri gibi rakamla ölçülemeyen soyut etkenler yer almaktadır. Birçok şirket ve yönetici bu değerleri gözardı edebilmekte, önlerine gelen finansal tablolarla ilgilenerek sürdürülebilir rekabet avantajında önde olduğunu düşünebilmektedir. Doğrudur, tablolar yalan söylemediği için önde olduklarını görmektedirler fakat bahsettiğim soyut konuların da uzun vadede çıktısı sürdürülebilir rekabet avantajına olumsuz yönde etki edebilmektedir. Şirketin rekabet üstünlüğünde önde olmasını sağlayan en temel faktör çalışanlar olduğundan çalışanların motivasyonu ve mutluluğu sürdürülebilir rekabet avantajını direkt olarak etkilemese de büyük ölçüde etkilemektedir.

Firmalar kaynaklara dayalı rekabet avantajına sahip oldukları zaman inovasyon konusunda problem yaşayabilmektedirler. Sahip oldukları kaynakların (insan, ürün, hizmet vb.) efektif kullanımı ile sürdürülebilir rekabet avantajı elde edilmiş, her şey mükemmel gidiyor olabilir. Bu durumda bile firmaların yapması gereken en temel şey sanki rekabet avantajının kendilerinde olmadığını düşünerek hareket etmesidir. Yani, rekabet ve çevre analizi yapmaya devam etmeli, müşteri isteklerinin ne yöne gittiğini iyi algılamalı ve rakip firmaları da iyi takip etmelidir. Bir firmanın güncel durumda sahip olduğu bütün kaynaklar o an için etkili çalışabilir ama bundan sonraki dönemlerde de etkili olacağına işaret etmeyebilir. Bu açıdan baktığınız zaman proaktif çözümler ve stratejilerin de sürdürülebilir bir şekilde devam etmesi gerekmektedir.

Oracle Database Firewall

2012-01-23T14:53:00.001+02:00

Oracle Database Firewall

Oracle Veritabanı ailesi ürünleri arasında yer alan Oracle Database Firewall bundan yaklaşık 1.5 sene önce, Oracle'ın Secerno şirketini satın almasıyla Oracle'a katılmıştır. Oracle, veritabanı güvenliği başlığı altında, izleme ve bloklama özelliğine sahip, ağ katmanında yer alan Database Firewall ürününü geliştirmeye devam etmektedir. Kurulumu, yönetimi ve yapılandırılmasının yapılması oldukça kolaydır. Rakip ürünlere göre de oldukça düşük maliyetli ve birçok özelliği bünyesinde bulunduran bir üründür. Aynı zamanda lisanslanma metodu olarak da uyumludur.

Oracle Database Firewall'un teknik özelliklerine ve yapısına geçmeden önce birkaç istatistiki değer açıklamak istiyorum.

2011 Veri İhlalleri Araştırması Raporuna göre;

- Saldıralın %99'u hacking ya da kötü amaçlı yazılımla (malware) gerçekleştirilmektedir.

- Firmalar, sistemlerinden veri çalındığının farkına %86'lık bir istatistikle üçüncü parti bir kaynak aracılığıyla varıyor.

- Firmalar verilerinin çalındığını %9'luk bir istatistikle kendi çalışanlarından öğrenebiliyor ve fark edebiliyor.

- Neredeyse bütün ihlaller pahalı bir aksiyona gerek kalmadan atlatılabiliyor.

- Cloud mimarisi ihlal sayısını arttırmamıştır.

- Organizasyonlara izinsiz girişler hala karmaşık saldırılar gerektirmemektedir ve çoğu zaman basittir.

- İstatistiklere göre "hacking", ihlalleri arasında en fazla veri SQL Injection metodu ile çalınmaktadır.

- İstatistiklere göre saldırıların hedefleri %56'lık oranla perakende ve sağlık sektörüdür. Bu oranı %35 ile finansal hizmetler sektörü izlemektedir.

Oracle'ın sunduğu veritabanı güvenliği ürünleri aşağıdaki gibidir;

KuppingerCole'a* göre birçok ortam için güvenliğin başlangıç noktası DBFW ve Audit Vault. Oracle veritabanının bulunduğu bir ortamda, Oracle güvenlik ürünlerinin değerlendirilmesi tavsiye edilmektedir. Oracle, veritabanı güvenliği pazarında en geniş ürün yelpazesine sahip firmadır ve her açıdan veritabanını korumaktadır. (* KuppingerCole bir araştırma ve analiz şirketidir).

Oracle Database Firewall ağ katmanına kurulumu yapılan ve yönetilen bir üründür. DBFW'a korunmasını istediğiiz veritabanlarını gösterebilirsiniz. Bu veritabanları Oracle, Sybase, DB2, SQL Server veya MySQL(5.1 versiyonu ile) olabilir. DBFW, ağ katmanından veritabanına doğru gitmekte olan SQL sorgularının analiz, izleme, bloklama, değiştirme ya da direkt olarak veritabanına iletme görevini üstlenmektedir. Geliştirilen özel yapısı sayesinde SQL Injection saldırılarını rahatlıkla anlayabilmekte, bu tipte saldırıları bloklayabilmekte ve istenildiği takdirde belirli alıcılara mail olarak gönderebilmektedir. SQL Injection saldırılarını SQL'in yapısını inceleyerek anlayabilmektedir. Çok yüksek düzeyde veritabanı güvenliği sağlamaktadır. Oluşturabildiği güvenlik politikaları ve listeleriyle hangi sorgunun veritabanına iletilmesini istediğinizi ya da istemediğinizi rahatlıkla tanımlayabiliyorsunuz. Aynı zamanda gerçek zamanlı raporlama ve bloklama özelliğine de sahip bir üründür.

İki tip DBFW koruma yöntemi bulunmaktadır;

- In-Line

- Out-of-Band

In-line koruma seçeneğinde bloklama ve izleme, out-of-band koruma seçeneğinde ise yalnızca izleme özelliği kullanılabilmektedir. In-line bağlantı için kurulacak DBFW ile korunacak veritabanının IP-briged bir ağ yapısına sahip olması gerekmektedir. Bu sayede veritabanına gelmekte olan sorgular DBFW tarafından önce incelenir ve uygun görülürse veritabanına gönderilir. Bu işlemin zaman kaybını son kullanıcı asla anlamaz (milisaniyelerle ölçülen bir eşleştirme söz konusudur). Out-of-Band koruma seçeneğinde ise switch üzerinde SPAN portu tanımlanır ve DBFW'un bulunacağı Linux makineye IP Mirroring yapılır. Veritabanına giden bütün SQL sorguları aynı zamanda DBFW'un olduğu sunucuya da gönderilir. Bu durumda bloklama özelliği devreden çıkar ancak anlık raporlama ve analiz işlemleri devam eder. Bu sebepten dolayı Oracle tam koruma için DBFW - Audit Vault - Database Vault üçlüsünü tavsiye etmektedir. In-line korumanın bir diğer etkili özelliği ise gelen SQL sorgularının yapısını değiştirebilmesidir.

Bir ortamda birden fazla DBFW ve DBFW Yönetim Sunucusu (Management Server) bulunabilmektedir. DBFW ve DBFW Yönetim Sunucusu aynı makine üzerine kurulabilir.

Bir veya Birden Fazla Oracle Database Firewall

- Yönetim sunucusu gerekmektedir.

- Gerçek zamanlı trafik kayıtları ve SQL transaction analizleri.

- SQL transaction'larının kategorize edilmesi.

- Kara, beyaz ve ayrıcalık listelerinin oluşturulması ve uygulanması.

- Gerçek zamanlı uyarılar ve etkinlikler.

Bir veya Birden Fazla Oracle Database Firewall Yönetim Sunucusu

- Bir veya birden fazla DBFW'dan SQL verilerini biriktirmektedir.

- İş raporları için bir raporlama platformu görevi görmektedir.

- Veri kontrol politikalarının merkezileştirildiği yerdir.

- Günlük (log) dosyalarının saklandığı ve yönetildiği yerdir.

- Bağlı bütün DBFW'ları uzaktan yönetebilmektedir.

- Üçüncü parti uygulamalarla entegre olabilmektedir (F5 BIG-IP ASM ve ArcSight).

Bir veya Birden Fazla Oracle Database Firewall Analyzer

- DBFW'lar tarafından oluşturulan günlükleri okur.

- Microsoft Windows işletim sisteminde çalışan, grafiksel arayüzlü bir üründür.

- Politikaların yaratılması ve uygulanmasını sağlamaktadır.

Oracle Database Firewall Sistem Mimarisi

Oracle Database Firewall ürününün yukarıdaki gibi bir sistem mimarisi bulunmaktadır. Yukarıdaki mimari bir Out-of-Band koruma mimarisidir ve network switch üzerinde 2 tane SPAN portu tanımlanmıştır çünkü 2 adet DBFW bulunmaktadır (Oracle Database Firewall + Resilient Pair).

Oracle Database Firewall Sistem Mimarisi

Yüksek Erişilebilirlik (High Availibility)

Oracle Database Firewall ürünü yüksek erişilebilirlik mimarisinde de kurulabilmektedir. Herhangi bir DBFW sistemi kapandığı zaman diğer DBFW (Resilient Pair) işlere devam etmekte ve korunmakta olan veritabanları üzerinde işlemlere devam edebilmektedir. Aynı şekilde DBFW Yönetim Sunucularından birisi kapandığında diğeri bütün DBFW'ları yönetmeye ve log'ları okumaya devam edebilmektedir. Sistemler yeniden ayağa kalktığı zaman bütün DBFW ürünlerinin birbirinden haberi olmaktadır. Bu doğrultuda DBFW ürünleri felaket kurtarma çözümünün içinde de yer alabilmektedir. Her iki site'da yüksek erişilebilirlik özelliği ile toplamda 4 DBFW ve 4 DBFW Yönetim Sunucusu kurulabilir ve bütün hepsi birbirleri ile iletişim halinde kalarak, azami güvenlik önemi alınmış ve yönetilmiş olur.

Oracle Database Firewall Yönetim Ekranı (Administration Console)

- Web Tabanlı uygulama.

- DBFW'ın yapılandırılması, yönetilmesi ve izlenmesi.

- Her DBFW'da ya da DBFW Yönetim Sunucusunda bulunmaktadır.

- Yalnızca "System" tabına sahiptir ve DBFW Yönetim Sunucusu Yönetim Ekranı kadar detaylı bir GUI değildir.

- Yönetim ekranının görüntüsü aşağıdaki gibidir ve yönetim ekranına web browser'a, yönetim ekranının ip adresini yazarak ulaşabiliyoruz;

Oracle Database Firewall Üçünü Parti Uygulamalar Entegrasyonu

- BIG IP Application Security Manager (ASM)

- f5 Networks Inc.

- Advanced Web Application Firewall (WAF).

- HTTPS ve HTTP taleplerinin analiz edilmesi.

- ArcSight Security Information Event Management (SIEM)

- syslog mesajlarının log'lanması, analiz edilmesi ve yönetilmesi için merkezileştirilmiş bir sistem.

Oracle Database Firewall Yönetim Sunucusu Yönetim Ekranı

(Management Server Administration Console)

- Korunan veritabanlarıyla ilgili en üst seviye bilgiler (tehdit durumu, veri akışları, top-10 tehditler).

- Tanımlanması ve yönetilmesi gereken DBFW'ların tanıtılması ve yönetilmesi.

- Uygulama noktalarının oluşturulması (Enforcement Points).

- Korunan veritabanlarının detaylarının kayıt altına alınması.

- Politikaların kurulması (listeleme ve yükleme).

- pdf ve/veya excel formatında çok çeşitli raporların oluşturulması ve zengin hazır rapor şablonlarıyla yönetim ve raporlama yapabilme imkanı.

- Raporların zamanlandırılması ve düzenli olarak çalıştırılması (bir e-posta adresine yönlendirilmesi).

- Önemli verilerin arşivlenmesi opsiyonunun barındırılması.

- DBFW'un en temel yapılandırma ayarlarının güncellenmesi (IP adresi, zaman ayarları-NTP).

- Yönetim ekranının görüntüsü aşağıdaki gibidir ve yönetim ekranına web browser'a, yönetim ekranının ip adresini yazarak ulaşabiliyoruz;

Oracle Database Firewall Desteklenen Veritabanı Yönetim Sistemleri

Oracle Database Firewall 5.1 versiyonu ile MySQL veritabanı da desteklenmeye başlanmıştır. Desteklenen MySQL versiyonları ise 5.0, 5.1 ve 5.5'tir.

Oracle Database Firewall 5.1 Yeni Özellikler

- Ağ şifreleme özelliği (network encryption).

- Proxy mode kurulumu.

- Genişletilmiş heterojen destek imkanı.

- Geliştirilmiş politika yönetimi ve ayarları.

- Geliştirilmiş raporlama seçenekleri ve rapor şablonları.

- BI Publisher il raporlama ve geliştirme.

- Kurulum seçenekleri

- MySQL veritabanı desteği.

Oracle Database Firewall ile veritabanının ağ katmanındaki güvenliğini rahatlıkla sağlayabilirsiniz ve istenmeyen SQL saldırılarına karşı kendinizi güvende hissedebilirsiniz.

Bütünleşme Stratejilerinde İnsan Kaynaklarının Rolü

2012-01-20T15:08:00.001+02:00

Bütünleşme Stratejilerinde İnsan Kaynaklarının Rolü

Dikey bütünleşme (vertical integration) bir stratejidir ve yönetim kontrol mekanızmasıdır. Dikey bütünleşmelerde, aynı tedarik zincirinde yer alan şirketler ortak bir yönetim altında birleşirler. Bu girişim aynı zamanda yatay bütünleşmenin kontrastıdır. Yatay bütünleşme (horizontal integration) stratejisi ise bir şirketin bir rakibini satın almasıdır.

Bütünleşme stratejilerinin ortaya konduğu ve gerçekleştirildiği durumlarda insan kaynakları departmanına da bir takım işler düşmektedir. Bu işlerin başında şirket çalışanlarını süreç hakkında bilgilendirme çalışmaları yer almaktadır. Bütünleşmenin herhangi bir çeşidine göre (ileriye doğru, geriye doğru veya yatay) fark etmez, İK her zaman çalışanları bilgilendirmelidir.

Büyük örgüt değişimlerinde çalışanların üzerindeki tedirginlik, iş kaygısı, haklarının kaybolacağı inancı, düzenlerinin bozulacağı baskısı artar. Bu baskının minimize edilmesinin yegane yollarından birisi bilgilendirmedir. Her bütünleşme ve örgüt değişim sürecinde çalışanların motivasyonlarının düştüğünü ifade edebiliriz. Bütünleşme stratejisiyle değişecek olan sistem, kültür ve iş rolleri ve tanımları iyi açıklanmalıdır. Değişim sürecinin başından sonuna kadar, değişimle ilgili sunumlar, çalışmalar yapılmalıdır. Sürecin aşamaları çalışanlarına dikkatlice anlatılmalı, performansı yüksek personel bu değişimden olumlu faydalanmalı (terfi, ücreti hak), demotivasyon kaynakları ortadan kaldırılmalı ve her şeyden önemlisi bütünleşme stratejisinin verimli bir şekilde sonuçlandırılması önemlidir. Çalışanların, stratejik değişimlerden pozitif yönde etkilendiği yapılan anketlerle ortaya konduktan sonra koruma stratejisi olarak varolan İK çalışmalarına devam edilmelidir. Bu yöntemle şirketin genel havası hep olumlu esmeye devam edecektir. Entegrasyon sürecinin sonlarında ve devamında çalışanların motivasyonları takip edilmeye devam edilmelidir.

İK'nın diğer rolleri arasındaki iş analiz görevi de yeni yapıda gündeme gelecektir. Farklı görevler ortaya çıkabileceği, varolanların da değişebileceği gerçeği ile İK yöneticileri ve diğer yöneticiler arasında iş tanım ve analizi çalışmaları yerine getirilmeli, departmanlaşmalar yapılmalı ya da halihazırda olan departmanlar lav edilmelidir.

Bütünleşme stratejisinin bir parçası da stratejinin ne kadar başarılı, verimli ve geçerli olduğunun tespit edilmesidir. Stratejik yönetim kararları gereği değişen örgütlerdeki çarpıklıklar, hiyerarşik problemler, satışların azalması vb. konuların normalden çok daha dikkatli takip edilmesi gerekmektedir. Bir entegrasyonun, organizasyon değişiminin başarını ortaya koyan faktörlerin iyi analiz edilmesi ve sürecin başarısının ölçülmesi gerekmektedir.

Günümüzde birçok şirket satın alma ve birleşme stratejilerini uygulamaktadır. Yeni bir pazara girebilmek için çoğu zaman en efektif yöntem şirket satın almaları ve sonrasında pazar geliştirmeleri görülür. Bu doğrultuda şirketin insan kaynakları departmanının fonksiyonel stratejileri de bu genel stratejiyi destekler bir yapıda olmalıdır.

'İş Hayatına Hazır mısınız?'', Oracle Akademi Kampüsümüzde Etkinlikleri

2012-01-17T11:50:00.001+02:00

Selamlar,

İş hayatına hazır mısınız, Oracle Akademi kampüsünüzdeki etkinliklerimize 18 Ocak 2012 Çarşamba günü TOBB ETU'de devam edeceğiz.

İçerikle ilgili bilgiye ulaşmak için tıklayınız.

İyi çalışmalar.

Ogan

Stratejik İnsan Kaynakları Yönetimi ve İnsan Kaynaklarının Gelecekteki Rolü

2012-01-17T11:16:00.003+02:00

Stratejik İnsan Kaynakları Yönetimi

İnsan Kaynaklarının Gelecekteki Rolü

İnsan kaynakları yönetiminin bir fonksiyonel yönetim aracı olarak şirketin kurumsal stratejik yönetimine katkı sağlaması gerektiğini günümüzde birçok şirket kabul etmiş durumda. Tıpkı satış yönetiminin stratejiye somut olarak destek olması gerektiği gibi insan kaynaklarının da stratejiye ciddi anlamda destek olması gerekmektedir. Bunun en büyük nedeni gelişen teknoloji ve çevre ile birlikte değişen müşteri ve çalışan talep ve istekleridir.

İnsan kaynakları yönetimi son yıllara kadar yalnızca işe alımlara destek olan ve eğitimleri düzenleyen bir fonksiyon olarak görülmekteydi. Şirketlerin turn-over oranlarındaki artış, müşterilerin artan isteklerini karşılamakta zorlanan personel ve motivasyonu azalan çalışanların yarattığı çıkmazla birlikte insan kaynaklarının asıl görevi değişmektedir. Bu görev doğrultusunda İK departmanı çalışan anketleri, mülakatlar, gözlemler ve testlerle çalışanlarını anlamaya çalışmakta ve bu çıkmazdan kalıcı olarak kurtulmayı hedeflemektedir. Çalışmaların sonucunda çıkan cevaplar doğrultusunda da yenilikçi İK çalışmaları ile bütün süreç desteklenmekte, fonksiyonel stratejiler üretilmekte ve genel stratejiye destek olunmaktadır.

İnsan kaynakları departmanı olağanüstü durumlarda da şirketi desteklemek durumdadır. Bu olağanüstü süreçlere örnek olarak şirket satın almaları ve birleşmeleri, dikey ve yatay bütünleşme stratejileri ile çeşitlendirme, yoğunlaşma ve pazar geliştirme stratejileri de verilebilmektedir. Stratejik yönetim bu kararları alırken şirketin karlılığını arttırmayı ve büyümeyi hedeflemektedir. Tabi kararların genelinden İK fonksiyonu etkilendiği gibi bütün fonksiyonlar da etkilenmektedir. Belki de bu süreçlerin tamamından direkt olarak etkilenen tek fonksiyon İK fonksiyonudur ve süreç devam ederken; şirketin motivasyonunun yüksek tutulması, çalışanların entegrasyon hakkında bilgilendirilmesi, İK stratejilerinin yenilenmesi ve diğer bütün İK görevlerinin yerine getirilmesi gerekmektedir.

Her stratejik adımdan sonra şirket çalışanları üzerinde demotivasyon oluşturabilecek faktörler meydana gelmektedir. Bu faktörlerin çok ufak bir kısmı, motivasyonu ve şirket inancı yüksek olan çalışanlar tarafından absorbe edilirken büyük bir kısmı da çalışanların şirketten ayrılmasına kadar süreci götürmektedir. Peki bütün bu gelişmeler meydana gelirken İK departmanları nasıl davranmaktadır? Araştırmalar gösteriyor ki şirketlerin büyük bir çoğunluğu İK geliştirme araştırmaları yapmakta ancak bu araştırmaları değerlendirmemektedir ya da değerlendirmekte etkin olamamaktadır. Yapılan çalışmaları değerlendirmedikleri için de bir efor harcanmakta ve boşa gitmektedir. Araştırmaları olumlu olarak değerlendiren ve eylem planları oluşturabilen nadir şirketler ise bir amaca ulaşabilmek için gereğinden fazla çaba ve zaman harcamakta, maliyetleri yükseltmektedir.

İnsan kaynakları departmanları neredeyse bütün şirketlerde bulunmaktadır. Şirketlerin büyüklüğüne göre işe alımdan eğitime, iş analizlerinden hukuki süreçlere kadar görevlerini yerine getirmektedir. Şirket bir insan kaynakları yönetimi şirketi değilse insan kaynakları yönetimi, şirketin temel yeteneği içinde bulunmamaktadır. Bir şirketin stratejik yönetiminin ilgilendiği faktörler arasında da temel yetenek veya yetenekler bulunmaktadır. Bu argümana göre bir şirket bünyesinde İK departmanı hiç bulunmadığı ve hiçbir insan kaynakları elemanı olmadığı takdirde de stratejik hedeflere ulaşılabilir. Ancak burada şöyle bir problem var, “motivasyon”. Bana göre İK departmanının en önemli görevleri arasında motivasyonu etkileyici yönüyle iş analizi bulunmakta. Hatırlayalım, her yöneticinin biraz insan kaynakları yöneticisi gibi olması gerektiğini. Bu bağlamda İK departmanı bulunmayan bir organizasyonda İK görevleri diğer yöneticilere kalmaktadır. Bunu, birbirini peşpeşe takip eden bir zincir gibi düşünebilirsiniz.

Rekabetin ciddi anlamda derinleştiği ve şirketlerin ayakta kalmakta zorlandığı, şirket birleşmeleri ve satın almalarının arttığı günümüzde katkıları daha çok soyut olan insan kaynakları departmanına çok daha fazla görev düşmektedir. Bu doğrultuda insan kaynakları departmanları gelişmektedir ve organizasyondaki motivasyonu düzenleyici rolü artmaktadır. İnsan kaynakları departmanının rolü arttıkça da şirketin temel yeteneği ile arasında olan ilişki azalmakta ve şirket içerisinde büyümesinin önü kesilebilmektedir. Büyümesinin önü kesilen insan kaynakları departmanı da gelişememekte ve şirket içerisindeki motivasyonu kontrol altında tutamadığı için şirket çalışanları demotive olmaktadır. Bu çelişkiyi ortadan kaldırmanın stratejik yolu insan kaynakları departmanında kısmi ya da tamamen olarak dış kaynak kullanımına gidilmesidir. Peki hangi insan kaynakları rollerinin dış kaynak kullanımı ile yerine getirilmesi daha etkindir?

İnsan kaynakları departmanının işe alım, eğitim, iş analizi, hukuki, beşeri, motive edici vb. rolleri olduğunu biliyoruz. Bu rollerin yerine gelmesi için şirket bünyesine yeni insanlar katılır ve bu insanlar insan kaynakları departmanını oluşturur. Belirttiğim nedenlerden dolayı artık bu departman şirket bünyesine sığmamaktadır. Sığmadığı yerde mutlaka dış kaynak kullanımına gidilmelidir. Bu konudaki dış kaynak kullanımı oldukça faydalı olabilir zira dış kaynak kullanılan firmanın performansının değerlendirilmesi oldukça basittir, çalışan anketleri. Küresel bir firmada lokal insan kaynakları danışmanının bulunması daha yararlı olacaktır. Bir ya da birkaç kişiden oluşacak bu grup, lokal soruları ve işleri yerine getirirken, küresel şirketin belirli noktalarında konuşlanmış İK dış kaynak şirketleri de kalan bütün İK görevlerini yerine getirecektir. Bu dış kaynak şirketi, lokal İK’nın geri beslemelerinden ve yorumlarından faydalandığı gibi küresel çözümleri lokal yaklaşımlarla eşleştirerek yaratıcı çözümler üretecektir. İş analizi konusunda da lokal kaynaklardan gelen bilgilere dayalı iş tanımları ve roller oluşturacaktır. Kendi sektörümden bir örnek vermem gerekirse, merkezileştirilmiş bir yazılım yönetim konsoluna bağlı lokal ajanlar.

Bir insan kaynakları departmanının gelecekteki rolü kesinlikle motivasyonu iyileştirmek ve daha da doğru insanı, doğru noktalardan bulmak, yetiştirmek ve geliştirmek olacaktır. Bundan 100 yıl önce bana savaşı tanımla deseydiniz ben size silah derdim ama şimdi “beyin ve bilgi”. Günümüzde de şirketler sonuna kadar doğru stratejileri uygulasalar, satış rekorları kırsalar bile artık her şirket çalışanına ne verdiği ile de değerlendiriliyor ve doğru insanları, yeni yetenekleri bulabilmek için çaba harcıyor. Ne yazık ki birçok şirket bünyesindeki yetenekleri göremiyor ya da görmek istemiyor. Hal böyle olunca şirket bünyesindeki başarılı insanlar işten ayrılıyor veya ayrılmasalar bile demotive çalışmaya ve isteksiz davranmaya devam ediyor. Şirketler, daha da kapitalist davrandıkça bünyesindeki elemanın mutsuzluğu yükseliyor ve mutsuz bir ekip ortaya çıkıyor. Tek amaçları daha çok satmak, satmak ve satmak oluyor. Bütün bu verileri konsolide ederek çalışanına verdiği değeri en üst seviye çıkartıp insani faktörleri de bir bilanço, bir nakit akış tablosu gibi değerlendiren şirketler rekabette uzun vadede üstünlük elde edecektir.

Yeni Başlangıçlar için 2012

2011-12-29T14:34:00.000+02:00

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

SWITCH DATAFILE ALL ve ORA-01157

2011-12-23T11:15:00.001+02:00

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

DDL_LOCK_TIMEOUT

2011-11-02T16:38:00.001+02:00

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

Yeni, Türk Oracle ACE! - Gökhan ATIL

2011-10-27T10:07:00.000+03:00

Merhaba Arkadaşlar,

Türk Oracle topluluğumuza bir Oracle ACE üyesi daha katıldı! Gökhan'ı tebrik ediyorum ve başarılarının devamını diliyorum. Her zamanki gibi gurur duyduk :)

Gökhan'ın ACE profili için tıklayınız.

İyi çalışmalar.

Ogan

Stratejik Karar Alma ve Dış Çevre

2011-10-20T10:04:00.000+03:00

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"

2011-10-20T09:54:00.003+03:00

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

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

2011-10-06T14:59:00.002+03:00

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

ThinkQuest Yarışması

2011-09-29T21:01:00.000+03:00

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

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

2011-09-15T16:13:00.001+03:00

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

2011-09-15T15:26:00.000+03:00

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

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

2011-09-13T09:28:00.002+03:00

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.

Materialized View

2011-09-08T13:47:00.000+03:00

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

External Table

2011-08-18T10:11:00.000+03:00

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

Flashback Data Archive & Total Recall

2011-08-16T13:38:00.001+03:00

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

CTIS 2011 by Erkan Uçar

2011-07-22T14:36:00.000+03:00

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

Oracle Open World 2011

2011-07-04T19:47:00.000+03:00

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

TROUG Day 2011 Sunum Video'ları

2011-06-22T10:22:00.000+03:00

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

Oracle Türkiye

2011-06-21T12:48:00.001+03:00

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?

2011-06-21T12:36:00.000+03:00

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