Wintel Bitiyor Mu?

Son günlerde teknoloji dünyasına bomba bir haber düştü. Qualcomm ile Microsoft iş birliği yaparak x86 emülatoru yaptılar. Bu emülato üzerinde windows 10 çalıştırıldı. Bu gerçekten güzel bir gelişme oldu. Güzel olduğu kadar da bir o kadar yan etkileri olacak bir gelişme olabilir. Acaba yıllardır süregelen wintel tekeli artık yolun sonuna mı gelmişti?

Microsoft mobil sektörde olmak için çok uğraştı. Dev yatırımlar yaptı, satın almalar yaptı. Fakat Microsoft istediği hedefe henüz ulaşamadı. Firma hedeflerinden vazgeçmiş değil. Kapalı kapılar ardında yeni stratejiler geliştiriyor. Microsoft, arm tabanlı SoC üretiminden sektör lideri olan Qualcomm iş birliği yaptı ve ortaya bir x86 emülator çıktı. Bu emülator ile CISC mimarisi üzerine kurulu olan x86 komut setlerinin RICS mimarisi üzerine kurulu olan snapdrogan 820 üzerinde windows 10 çalıştıyordu. Emülatorun biraz geçikme ile çalıştığı söylense de kullanıcı deneyimini olumsuz etkilediği görülmüyor. Aşağıda yapılan bir demo videosunu paylaşıyorum. Demo youtube üzerinden resmi windows kanalında yayınlanmış.

Qualcomm yakın zamanda 830 ve 835 SoC çözümlerini piyasaya sürecek. Snapdragon 830 ve 835 SoC üzerinde emülatorun geçikmesinin sıfıra ineceğini müjdeleyerek heyecanı artırdı. Microsoft’un neden bir yolu tercih ettiğinin nedeni basit. Mobil tarafta arm tabanlı windows geliştirdi ve ortaya çıkan windowsu gerek geliştirciler gerekse kullanıcılar tarafından benimsenmedi. Mobil sektörde Microsoft’un pazar payı yok denecek kadar az. Android ve iOS sektörü silip süpürüyor. İşletim sistemi tarafından x86 mimarisi dışında diğer mimarileri de destek vermek yerine x86 ile yola devam etmek istiyor. En iyi bildiği işi yapmak istiyor. Arm mimarisi karşından x86 mimarisinin avantajları iş mobilitiye gelince iş tam tersine dönüyor, rüzgarlar Arm mimarisinden tarafı esiyordu. Microsoft’un mobilite trenine yetişmesi için taze kana ihtiyacı vardı. Qualcomm. Wintel tekeli için tehlike çanları çalmaya başlamış olabilir 🙂 Wintel biter mi? Bence bitmez. Hatta bu iş birliğinin ikisine de yarayacağını ön görüyorum.

Microsoft direkt olarak ARM ile çalışmak yerine Qualcomm gibi donanim üretici ile çalışıp orta-kısa vadede sonuç almak istemiş olabilir. Bu tamamen benim fikrim. Bu iş birliği diğer donanim üreticilerinin de iştahını kabartabilir. Ortaya surface tarzı mobilite yüksek cihazlar çıkabilir ki, beklentim tam bu yönde. Hem tablet hemde pc olarak kullanabilen, üstelik olabildiğince performanslı ve enerji tüketiminde cimri bir cihaz olması hiç fena olmaz. Bekleyip göreceğiz. Bu konu hakkında ilerde daha geniş bir yazı hazırlayıp paylaşmak istiyorum. Şimdilik bu kadar 😉

Reklamlar

Linuxte oracle servisinin yapılandırılması

Sunucularda her restarttan sonra eğer bir servis ayarlanmadıysa oracle veri tabanı otomatik olarak başlamaz. Windows serverlerde kurulum yapıldıktan sonra otomatik olarak oracle servisleri de kurulumla birlikte hazır hale gelir. Linux sunucularda ise kurulum yaptıktan sonra bir linux servisi ile oracle veri tabanın sunucu ne zaman restart alırsa alsın servisler ile birlikte ayağa kalması için bir servis yapılmalıdır. Şimdi bu servisin nasıl yapılandırıldığını incelleyelim.

Sanal makina üzerine temiz bir CentOS kurulumu yaptım. Kurulum sonra Oracle 12c kurulumu yaptım. Oracle servisini ayarlamak için işe oratab  dosyasında değişiklik yaparak başlayalım.

Dosyanın tam yolu: /etc/oratab

Öncesi

#
# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third field indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
orcl12c:/u01/app/oracle/product/12.1.0/db_12c:N

Sonrası

#
# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME:<N|Y>:
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third field indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
orcl12c:/u01/app/oracle/product/12.1.0/db_12c:Y

Bu adımdan sonra /etc/init.d/ dizininde dbora dosyasını oluşracağız.

Dosyanın tam yolu /etc/init.d/dbora

Dosyanın içeriği

#!/bin/sh
# chkconfig: 345 99 10
# description: Oracle auto start-stop script.
#
# Set ORA_OWNER to the user id of the owner of the 
# Oracle database software.

ORA_OWNER=oracle

case "$1" in
    'start')
        # Start the Oracle databases:
        # The following command assumes that the oracle login 
        # will not prompt the user for any values
        # Remove "&" if you don't want startup as a background process.
        su $ORA_OWNER -c "/home/oracle/scripts/startup.sh >> /home/oracle/scripts/startup_shutdown.log 2>&1"

        touch /var/lock/subsys/dbora
        ;;
    'stop')
        # Stop the Oracle databases:
        # The following command assumes that the oracle login 
        # will not prompt the user for any values
        su $ORA_OWNER -c "/home/oracle/scripts/shutdown.sh >> /home/oracle/scripts/startup_shutdown.log 2>&1"
        rm -f /var/lock/subsys/dbora
        ;;
esac

Dosyayı oluşturduktan sonra /home/oracle/scripts dizinin iki tane dosya oluşturacağız. startup.sh ve shutdown.sh dosyaları.

startup.sh dosyasının içeriği

#!/bin/bash

export TMP=/tmp
export TMPDIR=$TMP
export PATH=/usr/sbin:/usr/local/bin:$PATH
export ORACLE_HOSTNAME=centos7.oracle12c.local
export ORACLE_UNQNAME=orcl12c

export ORACLE_SID=orcl12c
ORAENV_ASK=NO
. oraenv
ORAENV_ASK=YES

# Start Listener
lsnrctl start

# Start Database
sqlplus / as sysdba << EOF
STARTUP;
EXIT;
EOF

shutdown.sh dosyasının içeriği

#!/bin/bash

export TMP=/tmp
export TMPDIR=$TMP
export PATH=/usr/sbin:/usr/local/bin:$PATH
export ORACLE_HOSTNAME=centos7.oracle12c.local
export ORACLE_UNQNAME=orcl12c

export ORACLE_SID=orcl12c 
ORAENV_ASK=NO
. oraenv
ORAENV_ASK=YES

# Stop Database
sqlplus / as sysdba << EOF
SHUTDOWN IMMEDIATE;
EXIT;
EOF

# Stop Listener
lsnrctl stop

Dosyaları oluşturduktan sonra root user ile aşağıdaki komutlar çalıştırılır.
chmod 750 /etc/init.d/dbora
chkconfig --add dbora

Artık sunucu üzerinde dbora isimli bir servis var. Sunucu restart olduktan sonra servis otomatik olarak başlayacaktır. Kontrol için

systemctl status dbora

systemctl status

Kaynaklar

https://oracle-base.com/articles/linux/automating-database-startup-and-shutdown-on-linux

 

odi jconnect_implicit hatası ve sybase dynamic_prepare parametresi

odi 11.1.1.9 sürümünde sybase ile çalıştırken update işlemlerinde jconnect_implicit hatası verir. jconn2.jar dosyasını kullanarak bağlantılarda bu hata alınmaktadır.  Odi 11.1.1.9 sürümünden önce 11.1.1.5 sürümünü kullanımda bu tür hata alınmıyordu. ve odi 11.1.1.9 sürümü ile update işlemlerinde hata vermeye başladı. Operatörden update sqllerine bakıldığında update sqlleri farklı olduğu görülecektir.

odi 11.1.1.5 sürümündeki update

Update    proddb.dbo.table_1
set     col4    = s.col4,
    col5    = s.col5      
from    proddb.dbo.I$_table_1     S,
    proddb.dbo.table_1     T
where    T.col1    = S.col1
and    T.col2    = S.col2
and    S.IND_UPDATE    = 'U'

odi 11.1.1.9 sürümündeki update

update    proddb.dbo.table_1 
    set     col4    = :new_value4,     
           col5    = :new_value5     
where    col1    = :new_col1 
       and    col2    = :new_col2

Bu hatayı çözmek için topolojide aşağıdaki gibi ayarlar yapılmalıdır. properties sekmesinde DYNAMIC_PREPARE parametresi girilerek değeri true olarak ayarlanmalıdır. Özellikle belirtmek istiyorum ki bu hata jconn2.jar dosyasını kullanarak  Odi 11.1.1.9 sürümünde karşılaşılabilir. DYNAMIC_PREPARE parametresini false olarak ayarlansa da jconnect_implicit hatası vermemektedir. Parametrenin ayarının nasıl yapıldığının ekran görüntüsü aşağıdadır.

 

odi

Madem bağlantıda DYNAMIC_PREPARE parametresini set ediyoruz, true yada false yapmamızın sybase server tarafında nasıl bir etki yapacağını da anlatayım. Eğer değeri true olarak verilirse, sybase server gönderilen sql sorguları stored procedüre gibi çalışırır. Bu şekilde çalışması veri hacmi büyüdükçe performans kazancı sağlar. Eğer değeri false olarak verilirse, sql sorguları LWP (lightweight procedures) olarak çalışır.

 

Web Mining

Günümüzde internet başta iletişim olmakla beraber e-ticaret, reklam, bilgi ve belge paylaşımı,bankacılık işlemleri, kurumsal işlemler ve eğitim gibi birçok alanda kullanılmaktadır. İnternetin herkese açık olması, içerdiği bilgilerin her geçen gün daha düzensiz olmasına ve daha da artmasına neden olmaktadır.

Web madenciliği (web mining) terimi ilk kez Oren Etzioni tarfından 1996’da ortaya atılmıştır. Etzioni hazırladığı bildiride web madenciliği (web mining) tekniklerini kullanarak World Wide Web’de bulunan dosya ve servislerden otomatik olarak paternler bulmak ve öngörülmeyen bilgiye ulaşmayı web mining olarak tanımlamıştır. Etzioni’nin web mining tanımlaması bir çok araştırmada web mining tanımı olarak atıf bulunmuştur.

Web mining ise Madria tarafından Web’de bulunan veriden faydalı bilgiye ulaşmak olarak tanımlanmıtşır. Çeşitli yapıdaki web sayfası dokümanlarını, içeriklerini, link yapılarını ve kullanım bilgilerini incelemek, bunlardaki anlamlı bilgileri keşfetmek için veri madenciliği tekniklerinin kullanılmasıdır.

 Web üç tip veri bulundurur. Bunlar;

  • İçerik (content) verisi,
  • Yapı (structure) verisi,
  • Kullanım verisi (web log dosyaları)

İçerik verisi, web dokümanlarında, genellikle metin şeklinde yer alan verilerdir. Herhangi bir web sayfası üzerinde yer alan veriler bu tip için bir örnektir. Kullanım verisi, web sitesini ziyaret eden kullanıcıların oluşturdukları veri tipidir. Kullanım verisi genellikle hangi kullanıcı, ne zaman, hangi sayfaları ziyaret etti, ne kadar süre sitede kaldı gibi soruların cevaplarını içerir. Yapı verisi ise web sitesinin bağlantı yapısı hakkındaki verilerdir. Web sitesinde yer alan sayfaların hangi alt dizinler içerisinde bulunduğunu gösteren verilerden oluşur.

Web madenciliği ilk ortaya atıldığı dönemlerde Web İçerik Madenciliği (Web Content Mining) ve Web Kullanım Madenciliği (Web Usage Mining) olmak üzere iki sınıfa ayrılmaktaydı. Web madenciliğinin yaygınlaşması ile birlikte Web Yapı Madenciliği de (Web Structure Mining) üçüncü bir sınıf olarak eklenmiştir. Buna göre web madenciliği kullanılan verilerin yapısına göre 3 gruba ayrılır.

  • Web içerik madenciliği,
  • Web kullanım madenciliği,
  • Web yapı madenciliği

Web Kullanım Madenciliği

İnternet kullanıcıları web’de ziyaret ettikleri siteleride iz bırakırlar. Bu izlerde web’de dolaşırken yaptıkları erişim hareketlerince oluşturulan veriler bulunmaktadır. Bu izlerden log analizi yapılarak veri üretimi yapılır. Web kullanım madenciliği ise üretilen bu verilerden bilgi üretmeyi hedefler. Web kullanım madenciliği, ziyaretçinin siteyi kullanırken gerisinde bıraktığı erişim verilerinden bilgi üretmeyi amaçlar. Bu amaçla log dosyalarından en yoğun ve en ilginç kullanıcı erişim örüntülerini keşfetmek ve anlamlı verileri çıkartmak için veri madenciliği tekniklerini kullanır.

 Bu konudaki çalışmalar Genel Web Kullanım Madenciliği, Site Güncelleme Sistemleri, Sistem İyileştirme ve Kişiselleştirme başlıkları altında toplanabilir. Genel Web Kullanım Madenciliği Sistemleri kullanıcıların genel davranış biçimerini bilinen ya da önerilen veri madenciliği algoritmalarını sunucu erişim dosyalarındaki veriye uygulayarak bulmaya çalışır. Site Günçelleştirme Sistemlerinin hedefi ise site içerik ve yapısında yapılması gereken tadilatları bulmaktır. Sistem İyileştirme üzerine yapılan araştırmalar web kullanım verisini kullanarak trafiği etkinleştirmeyi hedefler. Son olarak, kişiselleştirme çalışmaları bireysel taleplere gore değişen siteler oluşturmaya çalışır.

Windows Server 2003 işletimi sistemi üzerinde çalışan IIS 6.0 web sunucusunda tutulan log dosyasından örnek bir satır verilmiştir.

2010-03-05 00:22:31 193.140.180.4 GET /Default.aspx – 80 – 212.154.80.164 Mozilla/4.0+ (compatible;+MSIE+6.0;+Windows+NT+5.1; +SV1;+GTB6.4) – 200 00 67049 428 31

Web kullanım madenciliği;

  • Ön işlem,
  • Örüntü keşfi,
  • Örüntü analizi

olmak üzere 3 aşamada gerçekleştirilir.

Ön İşlem; web sunucusu üzerinde tutulan log dosyalarından sağlıklı bilgi çıkarımı yapabilmek için gereksiz verilerden temizlenmesi ve belirli bir düzene sokulması gerekmektedir. Sunucular üzerinde karmaşık ve düzensiz bir şekilde tutulan log dosyalarındaki verilerin analiz değeri olmayan ilişkisiz verilerden temizlenmesi, belirli bir biçime getirilmesi ve veritabanına aktarılması işlemi ön işlem sürecidir. Ön işlem süreci web kullanım madenciliğinin en önemli ve en uzun süren basamağıdır. Bu süreç sonrasında veri örüntü keşfi için uygun hale getirilmektedir. Bu süreçte önemli olan verinin orijinalliğinin korunmasıdır. Ön işlem süreci veri temizleme, kullanıcı tanımlama, oturum tanımlama, yol tamamlama ve biçimlendirme olmak üzere dört adımda gerçekleşir. Verilerin temizlenmesi, kullanıcı ve oturum tanımlama aşamalarında sezgisel(heuristic) teknikler kullanılmaktadır. Web kullanım verisine VM tekniklerinin başarılı bir şekilde uygulanması, ön işlem sürecindeki işlemlerin doğru uygulanmasına büyük oranda bağımlıdır.

 Örüntü Keşfi; örüntü keşfi aşamasında ön işlem sürecinden sonra elde edilen düzenli ama anlamsız olan verilerden, veri madenciliği yöntemlerini kullanarak istenilen faydalı ve gerekli bilgilerin ortaya çıkarılması gerçekleştirilmektedir.

 Örüntü Analizi;  örüntü analizi web kullanım madenciliğinin son adımıdır. Örüntü analizinin amacı bulunan örüntülerden ilginç olmayan kuralları, istatistikî bilgileri ya da örüntüleri elemektir. Genellikle örüntü analiz işlemi web madenciliği uygulamaları tarafından elde edilir. Oracle,MS SQL SERVER, MySQL gibi veritabanı uygulamaları ve On-Line Analytical Processing (OLAP) yaygın olarak kullanılan bilgi sorgulama mekanizmalarıdır.

 Web İçerik Madenciliği

Web içerik madenciliği web kaynaklarından otomatik bilgi arama tekniklerini tanımlar. Web içerik madenciliği, web sitelerinin içeriğine yoğunlaşır. Verinin farklı tiplerde oluşu ve yapısal olmayışı bu konudaki tekniklere daha karışık yaklaşımlar kazandırır. Otomatik anahtar kelime anahtar kelime arama ötesinde, metinler içindeki bilinen yapıları bazı veri modellerine indirgeme yöntemleridir. İki tip veri madenciliği stratejisi olabilir; metin içeriklerini doğrudan arama ya da arama motorları gibi araçların aramalarını yardımcı olan.

Web içerikleri, içerik tarayıcı (Web Crawler) yazılımla taranır. Web Crawler yazılımları sadece siteleri arama motorları sonuçlarında listelemek haricinde, resim, video, makale, dosya, müzik vb gibi bir çok farklı format ve yapıdaki bilgiyi tarayabilmektedir. Bu yazılımlar ana sayfadan başlayarak verilen derinlik değerine göre linklerin gösterdiği sayfaları tarayarak sayfa numarası ve link adını istenen dosyaya yazar.

Web Crawler gibi çalışan ve içerdiği algoritmik farklılıkları olan tarayıcı başka yazılımlar da vardır. Bunlar robot yazılım olarak adlandırılır. Genellikle arama motorları tarafından bütün web sitelerinin taranmasını yaparlar. Web robot, web spider veya bot olarak ta adlandırılan arama motorları robotları olan bu bilgisayar yazılımları websitelerini dolaşarak gerekli bilgileri toplarlar. Bu içeriği toplarken sitenin alan adından, içeriğine, link yapısı ve site haritasına kadar bir çok farklı noktayı göz önünde bulundururlar, elbette sitenin indekslenmesi gereken alanları için robots.txt dosyasındaki yönlendirmeleri dikkate alırlar. Bu yazılımların güncel tam listesi user-agent-string (http://user-agent-string.info/list-of-ua/bots) sitesinde yayınlamaktadır.

 Web Yapı Madenciliği

Web yapı madenciliği, webteki bağlantıları bir çizge kuramı (graph theory) çalışması olarak görselleştirtirme süreci olarak düşünülebilir. Teknik olarak, dökümanlar arası bağlantılara yoğunlaşır. Web yapı madenciliğinin amacı web sitesi ve web sayfası hakkında bağlantı verisine bakarak bilgi üretmektir. Örneğin hangi sitelerin, hangi sitelere bağlantı (link) verdiği bilgisi bir grafik şeklinde çizilebilir. Buradan en çok bağlantı alan veya en çok bağlantı veren siteleri analiz etmek mümkündür. Benzer şekilde site içeriklerinde kullanılan bilgilerin de çizgeye dökülmesi ve analiz edilmesi mümkündür. Bir sitenin kendi içindeki bağlantı yoğunluğu veya resim yoğunluğu veya kullanıcı ile iletişimi sağlayan formların yoğunluğu site yöneticilerine veya site tasarımcılarına faydalı bilgiler sunabilir. Bu tip sitenin içeriğine yönelik analizler de yine web yapı madenciliğinin bir alanı olarak düşünülebilir.

 

 Kaynaklar;

  1. Oren Etzioni, The World Wide Web: Quagmire or gold mine. Communications of the ACM, 39(11):65­68, (1996)
  2. S.K.Madria, S.S.Bhowmick, W.K.Ng, and E.P.Lim, Research issues in Web data mining. In Proceedings of Data Warehousing and Knowledge Discovery, First International Conference, DaWaK ’99, sayfa 303­312 , (1999)
  3. Dr. Mehmet Sıddık Aktaş, Web Madenciliği,sayfa 12, (8 Mart 2014)
  4. Kosala, R., Blockeel, H., “Web mining research: a survey”,SIGKDD: SIGKDD explorations: newsletter of the special interest group (SIG) on knowledge discovery & data mining, ACM, 2(1): 1–15 (2000)
  5. Kantardzic M., “Data Mining:Concepts, Models, Methods and Algorithms”, John Wiley&Sons 2003
  6. Cooley, R., Mobasher, B., and Srivastava,J., “Data Preparation for mining World Wide Web Browsing Patterns”, Knowledge and Information Systems, 1:1–27 (1999).
  7. http://bilgisayarkavramlari.sadievrenseker.com/2012/03/17/web-madenciligi-web-mining/
  8. http://semsector.com/arama-motoru-robotu-web-crawler-nedir/
  9. http://www.teknoturk.org/docking/yazilar/tt000119-yazi.htm

Oracle 12c’de User Kavramı

Oracle 12 C ile birlikte hiç bir şey eski oracle sürümlerindeki gibi olmayacak 🙂 Hemen hemen herşeyi ile yep yeni bir mimari ile Oracle 12c karşımızda olacak. Şimdi Oracle 12c mimarisini nedir bakalım. Oracle 12c deki user kavramına başlayalım. Oracle 12c ile birlikte oracle cloud mimarisinde bir veri tabanı yönetim sistemini benimsedi (Ki zaten 12c de ki c takısı Cloud’u temsil eder, 10g ve 11g’de Grid, 8i ve 9i’de internet gibi ).  Bu mimariyi Oracle “Multitenant Architecture” olarak tanımlıyor. Bu mimari iki tip database içeriyor; Container Database (CDB) and Pluggable Database (PDB).  Container Database (CDB) and Pluggable Database (PDB) ne olduğunu bir sonraki yazımda anlatacağım. Kısaca deyinmek gerekirse Container Database (CDB) ana database ve Pluggable Database (PDB) ise Container Database (CDB)’den türetilmiş sanal bir database desek yanlış olmaz.

Oracle 12c userlar Local ve Comman User olmak üzere iki çeşide ayrıldı. Common user CBD’de yaratıldığı zaman, o anda var olan tüm PDB’de geçerlidir, ve var olacak PDB’de geçerli olacaktır. Common userların bütün instancelarda karakteristikleri aynıdır(ayni şifre,tablespace,… gibi). Uygulama yaparak bunları görelim. Common userların hepsinin ismi ya C## ile yada c## ile başlamalıdır.

CDB’de session almak için;

 alter session set container=CDB$ROOT;

Şimdi yeni bir user oluşturalım;

 create user C##USER1 identified by user1 container = all;

user ismini C## olmadan deneyelim;

 create user USER1 identified by user1 container=all;

hata verdi. Aldığımız hata;

SQL Error: ORA-65096: geçersiz ortak kullanıcı veya rol adı

Eğer create user ile birlikte “DEFAULT TABLESPACE, TEMPORARY TABLESPACE, QUOTA.. ON” gibi extra durumları belirtmek istersek, ayarlama yapılacak tüm objelerin bütün PDB ve CDB de olmalıdırlar.

Oracle 12c’de önceki sürümlerden farklı olan alışılmışın dışında bir mimari ve bu mimarinin kuralları ile karşılaşacağız.

Informatica Java Transformation

Java transformationda ETL transformasyonları için java programlama dilinin kullanılmasıdır. Java transformasyonda yapılacak transformasyon için java kodunun tamamını yazmaya gerek yoktur. Transformasyonun yapan kod parçacıkları yada bölümlerinin yazılması yeterlidir.  Java transformasyonundaki yazılan java kodları ile PowerCenter’deki mappingde bulunan expression, user-defined functions, unconnected transformations ve mapping değişkenlerine erişilip çağırılabilir. Java methodları, değişkenleri, üçüncü parti API’leri, Java paketlerine de kod içerisinde çağrılıp kullanılabilir. Java transmationlar tekrar kullanılabilir (re-usable) yapılabilir. Ayrıca transformasyona giren datanın satır sayısı ve port sayısı değiştirmeden kullanıldığında passive transformation, transformasyona giren datanın satır ve port sayısı değiştirecek şekilde kullanıldığında ise active transformasyon olarak kullanılabilir. Active yada Passive transformasyonun olacağına Java transformasyon mappinge dahil edilirken karar verilir. Daha sonrasında transformasyonun türünün değiştirilemez.

Geliştiricilerin kullandığı PowerCenter Client Java kodlarını derlemek için JDK kullanır ve java transactionları byte code çevirir. Java transformasyon kullanan bir session çalıştırıldığı zaman, Integration Service JRE’yi kullanarak byte kodları çalıştırır. Input portlardan datayı alıp işler ve output portlardan çıktıları üretir.

Java_transformation_intro_1

Java transformationu incelediğimizde dört tabtan oluşmaktadır. Genel seçeneklerin olduğu Transformation tabı, input ve output portlarının belirtildiği Ports tabı, active veya passive transformasyon seçeneklerinin olduğu Properties tabı, Java kod geliştirmesinin yapıldığı Java tabı bulunmaktadır. Portlar ve Properties seçenekleri ayarlanır ayarlanmaz, java kodlaması yapılmalı ve derlenmelidir. Compile linki pencerenin sağ alt tarafındadır. Java Code tabı ise yine tablara bölünmüştür. Bu tablar;

Java_transformastion_intro_2

  • Import Packages : 3. parti java paketlerini ve kendi geliştirdiğimiz java paketlerini import eder.
  • Helper Code : Java transformasyonlar için değişkenlerin ve methodların tanımlandığı sekmedir
  • On Input Row : input olarak alınan satırlarda sadece bir kez çalışacak java kodlamasının yapıldığı bölümdür. Bu tabtan sadece input portlarına erişilebilir.
  • On End of Data : input olarak alınan dataların işlenmesinden sonra neler yapılacağının tanımlanan tabdır.
  • On Receiving Transaction : Transaction işleminin başladığında çalıtırılacak java kodlarının tanımladığı tabdır.
  •   Java Expressions : Java kodlamasını yaptığımız tabdır.

Informatica java transformationda hazır olarak kullanacağımız java methodları vardır. Bunlar;

commit :     Transactionda commit yapar.
failSession (“hata mesajı”) :    Session başarısız olduğunda belirtilen hata mesajını verir.
generateRow :  Active transactionlarda çıktı olarak tanımlanan portları üretir.
getInRowType :  Transactionda input olarak kullanılan satırın tipini verir.
incrementErrorCount : Sessiondaki hata sayısını artırır.
isNull :  İnput olarak kullanılan porttaki datanın NULL olup olmadığını kontrol eder.
logError : Hata mesajlarını session loguna yazar.
logInfo : Bilgi amaçlı verilen mesajları session loguna yazar.
rollback : Transactionda rollback yapar.
setNull : Çıktı portu için NULL değerini atar.
setOutRowType :   Çıktı portları için update strategy ayarlaması yapar.

Tanımlamalar yapıldıktan sonra Compile tıklanır. Java kodları byte code cevirilir, Integration Service JVM ile çevrilen kodları çalıştırır ve data işlemeye başlar. Eğer java transformationda üçünçü parti jar dosyalarını kullacaksak, hem java transformasyonu hemde session bu jar dosyasını kullanacak şekilde yapılandırılmalıdır. CLASSPATH hem java transformationda hemde sessionda ayarlanmalıdır.

Sessionda CLASSPATH ayarlamak için

  • workflow managerde session penceresi açılır
  • Properties tabı açılır
  • Java Classpath seçilir
  • Gerekli olan jar dosyalarının yeri CLASSPATH’e eklenir.

Java_transformation_intro_3
Eğer sessionda classpathde jar dosyaları gösterilmezse üçüncü parti jar kullanan mappinglerin sessioni çalışmaz. Nedeni ise mappinge tanımlanımlanan jar dosyalarının derlenmesi sadece mapping geçerlidir. class dosyalarını session göremez. dosyaların yerinin gösterilmesi gerekmektedir. Bunun içinde sessionda da CLASSPATH ayarlanır.

Şimdi bir kaç örnek ile yukarıda anlattıklarımı pekiştirelim. Birinci örneğimizde flatfiledan veri okuması yapalım. Verileri çoklayarak hedef tabloya insert edelim. Source olarak kullandığım data aşağıdadır.

URUN_ID,URUN_ADI,SPEC_COUNT
1001,Klavye,1
1002,Monitör,2
2003,Anakart,3
2004,CPU,4
2005,RAM,5
2006,HDD,6

Mapping_2

Yukardaki mappingde flatfiledan okunan veriler java transformationa giriyor.  Java Transformationda SPEC_COUNT adetince çoklama yapıyor. Expression transformationda ise URUN_ID portu üzerinden bir rule ile URUN_TUR portu elde ediliyor. Mappingin açılmış hali aşağıdadır.

Mapping_1

Java Transformationda kullanılan java scripti

if(!isNull(“IN_SPEC_COUNT”))
{
int count = IN_SPEC_COUNT;
for(int i=0;i<count;i++)
{
OUT_URUN_ID    = IN_URUN_ID;
OUT_URUN_ADI    = IN_URUN_ADI;
OUT_SPEC_COUNT    = count;
generateRow();
}
}

Mapping geliştirmesi bittikten sonra workflow gelişmesine geçilir. Burada source olarak kullandığımız flatfile dizinin doğru verildiğini kontrol ederiz. Target connection seçilir. Target tabloya data nasıl aktarılacaksa gerekli ayarlar yapılır.

Workflow_1Workflow tasarımı bittikten sonra kayıt edilir. Workflow çalıştırılır. Aşağıda Workflow Monitorden çalışan Sessionu görüyoruz.

Monitor_1

Sessionda flatfileden okuma yapıp, sonra java transformasyonu yapıp, target tabloya dataları yüklemesi 2 saniye sürmüştür. Aşağıda ise istatistikleri görüyoruz. İstatistiklere bakıldığında ise sourcedan 6 satır kayıt okunmuş ve hedefe 21 satır kayıt atılmıştır. ETL beklenildiği gibi bitmiştir.

Monitor_2

TABLE_1

İkinci örneğimizde ise source olarak yine flatfile kullanıp RESELLER içerisinde datayı ‘#’ göre pars edelim. Source olarak kullandığım Data aşağıdadır.

PRODUCT_CODE,VENDOR_ID,CATEGORY,PRODUCT_NAME,MODEL,RESELLER
103,4008,Photocopiers,imageCLASS,2200,BILGE#TEKSAS ELEC
104,4001,Photocopiers,Digital Copier,PC1060,NUMBER#BOARD#FOURHILL
113,4015,Desktop Computers,Optiplex,GX400,MULTINEC#WATERVIT
114,4023,Desktop Computers,Optiplex,GX260,FOLIC#PENTOS
124,4003,Servers,PowerEdge SC,1500SC,VAND#MEDAN#NICA
125,4018,Servers,PowerEdge,6600,TAME#ARBU
135,4001,Photocopiers,Color Copier,HP290,HAMA#TIKE
136,4008,Laser Printers,LaserJet,1200se,AKLE#SEMI
180,4003,Laser Printers,Infoprint 1145dn,4545DN1QC,YUKA#FEMKA#COMPAL

Mapping tasarımında arada java transformasyondan başka transformasyon olmadan target tabloya data yüklenecek şekilde tasarladım. Tasarım aşağıdadır.

Mapping_4

Mapping_3

Java transformationda kullanılan java scripti;

String str=IN_RESELLER;
String[] temp;
String delimiter = “#”;
temp = str.split(delimiter);
for (int i =0; i< temp.length; i++){
OUT_RESELLER = temp[i];
OUT_PRODUCT_CODE = IN_PRODUCT_CODE;
OUT_VENDOR_ID = IN_VENDOR_ID;
OUT_CATEGORY = IN_CATEGORY;
OUT_PRODUCT_NAME= IN_PRODUCT_NAME;
OUT_MODEL = IN_MODEL;
generateRow();
}

Workflow tasarlarken Sessionda flatfile dizinin doğru verildiğine dikkat ediyoruz. Ve target bağlantısını kontrol ediyoruz.

Workflow_2İşlemler bitttikten sonra workflowu çalıştırıp workflow moniterde yapılan işlemlere bakıyor. Workflowdaki session başarılı olarak bitiyor.

Monitor_3İstatistiklerden kontrol edelim.

Monitor_4

Son olarakta target tabloya bakalım.

Monitor_4TABLE_2

Bu makalede Informatica Java Transformation anlattım. Açıklayıcı olması için basit örnekler ile ETL mappinglerinde Java Transformasyon nasıl yapılırı anlattım.  Bir sonraki makalemde görüşmek üzere..

Informatica Pushdown Optimization

Informatica Pushdown, Integration service tarafında ETL sürecinde geliştirilen mappinglerin tranformasyon işlemlerinin kaynak ve hedef veri tabanları tarafından yapılmasıdır.Pushdown’daki temel amaç datayı exract etmeden olabildiğince database içerisinde transformasyon işlemleri yaparak target tabloya yüklemektir. Informatica sessionlar pushdown kullanılacak şekilde konfükre edildiğince sonra Integration Service, tranformasyonları SQL’lere çevirir ve veri tabanlarına gönderir. Bu SQL’ler ile transformasyonlar kaynak ve/veya hedef veri tabanlarında yapılır.

Informatica veri tabanlarına bağlantı yaparken şu sürücüleri kullanır;

  • ODBC
  • Native Drivers

Eğer database bağlantısı için  ODBC sürücüleri kullanılarak bağlantı yapılırsa, pushdown native SQL üretir. Yani ANSI standartlarına göre SQL’leri üretir. Bu durumda database sunucunun gücünden tam olarak yararlanılmayabilir. Diğer taraftan native drivers ile database bağlantısı yapılırsa, pushdown olabildiğince database gücünden yararlanacak şekilde SQL üretecektir. ODBC sürücü ile ANSI SQL’lerin üretime sebebi olarak informatica bağlantı yaptığı database’in (ORACLE,MS SQL SERVER, Teradata, DB2,..vs ) ne olduğunu tam olarak çözümleyemediği için standart olarak her databasede  desteklenen ANSI SQL üretir. Ki durumda üretilen SQL’lerin database ile uyum problemi aşılmış olur.

 Pushdown Çeşitleri;

  • Two-Pass Pushdown,
  • Partial Pushdown,
  • Full Pushdown

 Two-Pass Pushdown:  Source ve Target databaselerde Transformasyonlar için SQL üretir.

Source databasedeki transformasyonlar içim;

  •  Source’dan gelen data ve transformasyonlar için SQL üretir.
  • SELECT SQL Cümleciklerini Üretir.

Target database için transformasyon SQL üretimi,

  •  Mapping’de Source’dan gelen data ve transformasyonlar için SQL üretir.
  • INSERT, DELETE ve UPDATE SQL Cümlecikleri Üretir.

Partial Pushdown: Mappinglerdeki transformasyonların sadece bir kısmı için SQL üretir. Source ve Target side olarak çalışır.

Source Side için üretilen SQL’in Pushdown Optimization Viewer ekran görüntüsü aşağıdaki gibidir.
Partial_Source

Target Side için üretilen SQL’in Pushdown Optimization Viewer ekran görüntüsü aşağıdaki gibidir.

 Partial_Target

Full Pushdown : Source tablolarının target databasede olması şartıyla kullanılabilir. Burada database gücünün ve esnekliğinin sonuna kadar kullanımı vardır. Üretilen SQL için ekran görüntüsü aşağıdaki gibidir.

full_pushdown

Pushdown Database Tarafında Çalışma Yapısı

Informatica, pushdown kullandığı zaman Integration Service databasede “PM_” ile başlayan viewler ve squenceler oluşturur. Session bitmeden önce bu oluşturulan database nesneleri silinir (Create & Drop). Bu işlemin yapılabilmesi için database bağlantısı olarak kullanılan kullanıcının Create view / Create squence haklarının da olması gerekir. Aksi halde pushdown kullanılan informatica sessionları başarılı bir şekilde sonlanmaz (fail olur).

Yararları

  • Aggregator, Lookup, Sorter ve Join işlemleri için Informatica Server’de RAM, Disk ve Cache kaynakları tüketilmez. Bu işlem databasede yapılır.
  • Session başlamadan önce Pusdown  Optimizer View ile üretilen SQL’ler görüntülenir. Bu ise daha kolay debug yapmamızı sağlar.
  • Eğer pushdown kullanılmasa insertler target tabloya row by row işlenir ve bind değişken kullanılır. Pushdown ise aynı işlemi tek seferde SQL cümlecikleri ile database gönderir. Bu durum bize beklemeyen sonuçları ile karşılaşma olasılığı düşüşü olarak geri döner.

Dikkat Edilmesi Gerekenler

  • Null Kayıtlar : Integration Service ile database’in öncelik sırası farklı olabilir. Null kayıtlar integration service için birinci sırada, databasede ise son sırada olacaktır.
  • SYSDATE : Değişkenlere atanan SYSDATE değeri problem çıkartabilir. Bu değişkenler için integration service ile database zamanın aynı olmasına ve session başlama zamanı ile databasede yapılacak işlemler arası zaman sekronizasyonun olup olmadığına dikkat edilmelidir. Integration Service ile database time zone ayarları farklı ise yine problem çıkması yüksek ihtimallidir.
  • Date Conversion : Integration service session başlamadan önce date conversion yapar. Eğer database’in desteklemediği bir formatta date conversion yapılırsa, session patlar.
  • Logging : Integration Service yapılan her işlemi loglamaz. Hata ayıklarken üretilen SQL’ler bize çok yardımcı olacaktır.

Daha İyi Pushdown İçin Öneriler

  • Source Qualifier : Olabildiğince source kısa yollarının kullanılması, gerekli olmayan portların (tablo kolonlarının) Source Qualifier’den çıkartılması, Varsayılan Query Optionları kullanmaya özen gösterilmeli ve eğer SQL Override yapacaksa tablo üzerinde partitionları kullanacak şekilde olmasına dikkat edilmelidir.
  • Expression : Gereksiz hesaplamalar için Local Variable kullanılmalıdır. Datatype Conversiondan mümkün olduğunca kaçınılmalıdır. Informatica dışı komutların kullanılmasından kaçınılmalıdır. Fonksiyonlar yerine (||,+,/,..vs) operatörler kullanılmalıdır.
  • Filter : Mapping’de Source Qualifier’e olabildiğince yakın yere konulmalıdır. Eğer birden çok filter kullanılacak filter yerine router kullanılmalıdır.
  • Aggregator : Mappin’de Source Qualifier’e olabildiğince yakın yerde Sorter kullanılmalıdır. Eğer filter kullanması söz konusu ise Aggregator’den önce kullanılmalıdır.
  • Joiner : Joinler eğer mümkünse Source Qualifier’de yapılmalıdır. Outer join yapmaktan kaçınılmalıdır. Master source olarak daha az daha ile çalışmak her zaman iyidir.
  • Lookup : Relational lookup, kriterlere uyan portu geri dönüş verir. Expressionlarda Unconnectted Lookup’lar çağırılmalıdır (IIF). Eğer büyük lookup tabloları ile çalışılacaksa lookup yerine join yapılmalıdır. Sessionda lookup cache kullanmamak için  cahce calculator kullanılmalıdır.

Uzun Süren Transformansyonlara Faydaları

  • Database Kaynaklarının Çok Fazla Tüketilmesini Engeller.
  • Eşzamanlık ve Locks; Database Nesneleri(Tablo ve View) için Eşzamanlılık Problemi Olmasını Engeller. İşlemler Uzun Sürmediği İçin Deadlockların Oluşmaz.
  • Beklenmeyen Durumların Olasılığı Düşer.

Fonksiyon Kullanırken Püf Noktalar

  • ADD_TO_DATE :  Teradata’da Pushdown yapımını engeller.
  • LAST_DATE : Oracle için saniye kadar dönüş yapar, saniye sonrasını trim yapar.
  • LTRIM,RTRIM ve SOUNDEX  : (‘ ‘) database için NULL, Integration Service (‘ ‘) boşluktur.
  • STDDEV ve VARIANCE :  DB2’de diğer databaseler ve Integration Servise göre farklı sonuç üretir.
  • SYSDATE ve SYSTIMESTAMP : Database ve Integration Service için farklı time zone farklı olup olmadığına dikkat edilmelidir.

Limitler

  • Database Bağımlı Çalışır.
  • Tablo Partitionları Problem Yaratabiliyor. SQL Override yaparken dikkatli olmak gerekiyor.
  • Bazı Fonksiyonlar Beklenmeyen Sonuçlar Üretebiliyor. Örnek: Teradata için Tarih bazlı fonksiyonlardan bazıları
  • Her Zaman Performans Sağlamaz.  Bazı durumlarda Compleks SQL üretir. Performans almak için Mappingleri Tekrar Tasarlanması Gerekebilir.
Reklamlar
%d blogcu bunu beğendi: