Yes, Fix Their Computer… With a rubber duck.

There is a popular saying in IT, “No, I will not fix your computer”. There are mugs, t-shirts and stickers of it.

   

I usually agree with this, since every time you help someone with their computer, you instantly become their computer guy, which is not good for your sanity.

Then two days ago, my engine stopped while I’m driving.

Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke

I pulled over, opened up the hood. Just stared at it for a minute, looking for a restart switch, went back inside and tried to start the engine. It started, with a frustrating vibration and almost no response to the gas pedal. I went back, looking under the hood and it hit me: This is how people feel when their computers are broken. Helpless, not knowing what was going on underneath, not even having a clue of how to fix it or what actually was causing the error. I had to call a friend of mine who is good with cars, and yes, he did fix my car.

From now on, I’ll at least try to fix people’s computers.

Thinking from the developers point of view, developers are not that helpless. They usually have the skills to figure out what’s going on when they face a challenge. But when it comes to undocumented software, like some application built in-house or even tool that can’t easily be googled, the urge to ask for someone’s help emerges. Asking for help is not a big deal, but what about providing it? Do we keep relying on “No, I will not fix your computer”? I don’t. I use a rubber duck instead.

And you can use the rubber duck for your own purposes too.

In a pinch a coworker might be able to substitute for the duck, however, it is often prefered to confide mistakes to the duck instead of your coworker.

I have a friend at work, he is my rubber duck. Every time I face a problem, I go to him and explain what the problem is. He sits there with his arms crossed and listens. At some point in conversation, I usually figure out what’s the issue. Vice versa, when someone asks for my help, before giving any ideas about the solution, I let them do the talking. I’m even thinking of placing an actual rubber duck on my desk.

And yes, I definetly am learning about engines so I won’t be helpless next time. Same thing goes with coding, too.

Etiketler

The 501 Developer Manifesto

I’ve been thinking and reading about The 501 Developer Manifesto lately. There are quite different opinions about it; I think the discussion gets stuck at the point when defining what a hobby, or free time is for each individual.

I agree with the fact that companies never should force employees to work a minute more than they are required to. But as software developers, most of us enjoy to study or research about the work we do, and do not consider it a free-time killer. I personally am preparing this post in a sunny Sunday, but as long as I enjoy it, it becomes a hobby of mine, not a free-time killer.

The Manifesto is so strict in terms that if you agree with it and count yourself as a 501 Developer, you might as well be a robot working in an assembly line. I chose to be a developer, because I love it. And I find myself to be a lucky man, considering the fact that I don’t actually have to work hard for a lifetime, because I usually enjoy what I do in company time. This is not dictated to me, this is not what my company requires me to do. What I do in my spare time is truly irrelevant, yet that seems to be the strong argument of the manifesto.

The Manifesto states:

To us it is just a job, but we still do it well.

In order to do this job well, you need to sharpen yourself. If your job does not require you to learn, research and master your skills, then you really are working in an assembly line. And if you’re OK with working in an assembly line… I respect you for it. There’s probably some pity in there too, but honestly, it’s mostly respect.

Final words for all, even though I don’t agree with most of it, this manifesto is a good step towards a better working environment. Its aim should actually be the managers and people that lead software development teams, not software developers themselves.

Etiketler ,

Turkcell PAF Takımı

Turkcell PAF Takımı programı ile Turkcell’de staj olanağı için başvurular başladı.

Başvurular 27 Nisan 2012 tarihine kadar açık olacak. 2010 yılında bu program kapsamında Turkcell Teknoloji’de staj yapmış birisi olarak daha önce izlenimlerimi yazmıştım.

Turkcell’de staja kabul edildikten sonra beklentilerim o kadar yüksek değildi, sonuçta benimle birlikte 30′a yakın stajyer vardı ve hepimizle ilgilenemeyeceklerini, zaten oldukça büyük bir yer olduğu için bilgisayarlarımızın başında kendi kendimizi eğitmeye çalışarak zaman geçireceğimizi düşünüyordum. Ama staja ilk başladığım günden itibaren bunun tamamen yanlış bir düşünce olduğunu anladım. Staj süresince bizler için ciddi eğitimler planlandı, oryantasyon sürecini rahat atlatabilmemiz için etkinlikler düzenlendi. Yöneticilerimiz teknik ve şirket kültürü anlamında fayda sağlayabilecek her toplantıya bizim de katılmamızı sağladı, standart eğitimlerin dışında kendi insiyatifleri ile eğitimler planladılar. Blog’da bu eğitimlerden çok ufak bir kısmını paylaşabildim sadece.

Şunu da eklemek isterim, bu bir reklam değildir :)

Etiketler , ,

Yıldız Teknik Üniversitesi Seminer Dersi

Bugün Emrah Mete ile birlikte eski bölümümüzde, Bilgisayar Mühendisliği ikinci sınıf öğrencilerine yarı teknik-yarı motivasyonel bir sunum yaptık, biz çok eğlendik sunum yaparken umarım dinleyenler için de aynı şey geçerli olmuştur :)

Katılan herkese teşekkürler..

Etiketler

Subclipse behind a proxy

Having plenty of experience with coding homeworks and projects for a long time now, me and my project partner Emrah decided to use an online source control system for our Senior Project at YTU and the first annoying problem appeared. After seeing that my friend Cem encountered the same problem today, I wanted to say a few words about it.

I’ve successfully installed Subclipse plugin for Eclipse. With a free account from XP-Dev I’ve set my SVN Repository up and checked out the root project using Subclipse to test the SVN server. Everything went as smooth as possible.

The next day, I wanted to use the Eclipse instance at work to check out the project. What a surprise, it failed with the following message..

RA layer request failed

After some digging, I’ve found Mark’s Post about this very issue. It turns out that Subclipse does not use the proxy settings defined in Eclipse Preferences. In a few words, here is the solution:

  1. For Windows, open file %APPDATA%\Subversion\servers.
  2. Find the section [global] at the bottom of the file and edit the related entries. Remember to uncomment them, and do not leave any spaces at the beginning of the line.
Etiketler , , ,

Eğitim Notları Hakkında

Benim eklemekte geciktiğim veya hiç ekleyemeyeceğim notlar olabilir, Bahar’ın blogundan da takip edebilirsiniz.

Eğitim Notları – 5

Yine biraz geç de olsa, Transactions konusundaki notlarım aşağıdaki gibidir. Kitapta bayağı ilerledik aslında, diğer notlarımı da en yakın zamanda eklemeye çalışacağım.

  • Transaction kavramı, bir veritabanını File System’den ayıran en önemli özelliklerdendir. Transaction’lar, veritabanını bir durumdan başka bir duruma geçirirler ve bunu atomik olarak yaparlar.
  • Bir veritabanı sistemindeki Transaction’lar ACID özelliklerini sağlamalıdır.
    • Atomicity : Ya hep ya hiç. Bir Transaction ya tamamlanır, ya da hiç çalışmamış gibi davranılır.
    • Consistency : Bir transaction veritabanını bir durumdan diğerine geçirir. Eksik veri ile bırakmaz.
    • Isolation :  Transaction COMMIT edilene kadar, o transaction’un değişiklikleri diğer Transaction’lara gözükmeyebilir.
    • Durability :  Transaction tamamlandığında, veri sağlama alınmış demektir.
  • Oracle’da bir Transaction, veriyi değiştiren yani ilk TX kilidini alan statement tarafından başlatılır, elle başlatılmaz. Bu noktadan sonra ya COMMIT ya da ROLLBACK ile Transaction sonlandırılır.
    • COMMIT : Değişiklikleri kalıcı hale getirir.
    • ROLLBACK : Değişiklikleri geri alır, Transaction çalışmamış gibi davranılır.
    • SAVEPOINT : Transaction içinde belli noktalara geri dönüş sağlayabilmek için kullanılır.
  • Tekrar söylemek lazım, DDL her zaman COMMIT edilir. DDL hata verse dahi o Transaction COMMIT edilir.
  • COMMIT ve ROLLBACK, o Transaction’ın elindeki kilitlerin hepsini kaldırır.
  • Eğer çalıştırılan statement bir trigger’ı tetikliyorsa ve bu trigger çalıştıktan sonra hata alınıyorsa, bu noktada yapılan ROLLBACK işlemi trigger’ın yaptığı değişiklikleri de geri alır.
  • PL/SQL bloklarında çalışan prosedürler de statement olarak kabul edilir ve atomiktir.

Son iki madde ile ilgili olarak aşağıdaki örnekleri inceleyelim ve örnekler için Thomas Kyte’a teşekkür edelim. Örnekte, T2 tablosu bir trigger yardımıyla T tablosundaki satırların sayısını tutmakla görevli. T tablosuna ise bir contraint sayesinde sadece sıfırdan büyük değerler girilebiliyor:

CREATE TABLE T ( x int check( x>0 ) );
CREATE TABLE T2( cnt int );
INSERT INTO T2 VALUES( 0 );
CREATE TRIGGER t_trigger BEFORE INSERT OR DELETE
    ON T FOR EACH ROW
BEGIN
    if (inserting) then
        UPDATE T2 set cnt = cnt + 1;
    Else
        UPDATE T2 set cnt = cnt - 1;
    end if;
    dbms_output.put_line( ‘I fired and updated ’ || sql%rowcount || ‘  rows.’ );
END;

Şimdi tabloya satır eklemeye çalışalım.

INSERT INTO T VALUES ( 1 );
I fired and updated 1 rows
1 row created.
INSERT INTO T VALUES ( -1 );
INSERT INTO T VALUES (-1 )
*
ERROR at line 1:
ORA-02290: check constraint (TKYTE.SYS_C001570) violated
I fired and updated 1 rows

Görüldüğü gibi, ilk satırı hata almadan ekleyebildik ve çıkış olarak ekrana trigger içerisinden “I fired and updated 1 rows” yazıldı. İkinci denememizde ise doğal olarak hata aldık, ancak aynı mesajı ekranda yine gördük. Yani trigger çalıştı, ve T2’deki satırı güncelledi. Bu noktada T2 tablosunda ‘2’ değerini görmeyi bekleriz. Ancak T2 tablosunda ‘1’ değeri bulunmaktadır. Yani Oracle, trigger içerisinde çalışan kodu da transaction’ın bir parçası olarak görür ve hata durumunda onu da geri alır. Diğer veritabanlarında tam tersi geçerlidir, trigger’lar kendilerinden sorumludur. Diğer sistemlerde çağırılan statement bir hata alırsa, trigger’lar kendi rollback işlemlerini yapmalıdırlar. Oracle’da statement’lar çağırılırken, aslında aşağıdaki gibi sarmalanır:

Savepoint statement1;
  Insert into t values ( 1 );
If error then rollback to statement1;
Savepoint statement2;
  Insert into t values ( -1 );
If error then rollback to statement2;

Eğer t_trigger’da içerisinde gerçekleştirdiği işlemler sonucunda başka bir trigger’ı tetikleseydi, hatta o da başka bir trigger’ı tetikleseydi bile, ilk ifadeye yapılan ROLLBACK sonucunda bütün trigger’ların gerçekleştirdiği işlemler geri alınacaktı.

  • PL/SQL blokları da statement level atomicity özelliklerini kullanırlar. Aşağıdaki prosedürü ele alalım:
CREATE OR REPLACE PROCEDURE p
AS
BEGIN
    INSERT INTO T VALUES ( 1 );
    INSERT INTO T VALUES (-1 );
END;

Bu prosedürün hata alacağını zaten biliyoruz. Burada soru şu; prosedür çağırıldıktan ve hata aldıktan sonra, T ve T1 tablolarının son durumu nasıl olacak? Burada p prosedürü bir statement olarak ele alınıyor ve ya hep ya hiç mantığı ile, ikinci INSERT hata aldığında bütün prosedür geri sarılıyor. İlginç noktalardan bir diğeri, eğer prosedürü aşağıdaki gibi çağırırsak:

BEGIN
    P;
EXCEPTION
    WHEN OTHERS THEN NULL;
END;

İkinci satır hata almasına rağmen, T tablosuna birinci satırın INSERT edildiğini görürüz. Bunun nedeni, yukarıda belirtilen sarmalama kodunda saklıdır. İkinci statement hata aldığında, “If Error then rollback” çalışamadan Exception yakalanır, ve böylece ROLLBACK yapılmamış olur. Buradan alınması gereken ders şudur, bir Exception bloğu transaction’un davranışını önemli ölçüde değiştirebilir.

  • Tablolar üzerindeki Integrity Constraint’ler varsayılan olarak SQL çalıştırıldıktan sonra kontrol edilir. Arka arkaya çalışan SQL’lerde de her SQL ifadesinden sonra kontrol yapılır. Bu işlemin sonra yapılmasının sebebi çok basittir, aşağıdaki örneği inceleyelim:
CREATE TABLE T (x int unique);
INSERT INTO T VALUES (1);
INSERT INTO T VALUES (2);
UPDATE T set x = x + 1;

Eğer her satır UPDATE edildikten sonra kontrol edilseydi, Unique Constraint ihlali yapılmış olurdu.

  • Integrity Constraint Check işlemini istersek erteleyebiliriz, ancak bu erteleme en fazla bir sonraki COMMIT’e kadar olabilir. Yani COMMIT, mutlaka yapılmamış Constraint Check’i yapar. Constraint Check işlemi her constraint için aşağıdaki şekilde ertelenebilir ve açılabilir:
SET CONSTRAINT <constraint_name> deferred;
SET CONSTRAINT <constraint_name> immediate;
  • Geliştirme yaparken, sadece COMMIT edilmesi gerektiğinde COMMIT etmeliyiz. Oracle’da transaction’lar için açılan kilitler pahalı değildir. Veri bütünlüğünden ödün vererek kilitleri kullanmamaya çalışmak saçma olur, çünkü kilitlerin Oracle’da maliyeti yoktur. Okuyucular yazıcıları, yazıcılar da okuyucuları beklemez. Transaction’lar veri bütünlüğünü korumak için vardır, hız kazandırmak için değil.
  • JDBC API kullanırken AUTOCOMMIT meselesine dikkat etmek gerekir. AUTOCOMMIT, her SQL ifadesinden sonra bir COMMIT çalıştırır, ve malum COMMIT çalıştırıldıktan sonra o veri geri sarılamaz.
Etiketler , ,

Eğitim Notları – 4

Expert Oracle kitabı üzerinden yaptığımız çalışmalar devam ediyor. Fırsat bulup da bu çalışmalarda aldığım notları eklemekte geciktim, bu yazıda Locking & Concurrency konusu üzerine olan notlarımı paylaşıyorum.

  • Locking & Concurrency, bir veritabanının birden çok kullanıcıya aynı anda hizmet verebilmesini sağlayan kontrollerden oluşur. Çoğu konuda olduğu gibi bu kontrollerin gerçeklenmesi her veritabanı sisteminde farklıdır. Lock, paylaşılan bir kaynağa erişimi düzenleyen bir kontroldür. Concurrency ise paylaşılan bir kaynağa birden çok kullanıcının aynı anda erişimini sağlayabilmek anlamına gelir. Yani bir lock, concurrency’yi sağlayabilmek için kullanılan kontrollerden biridir.
  • Locking ile ilgili genel olarak karşılaşılan bazı durumlar vardır. Bu durumlar kısaca aşağıdaki gibi açıklanmıştır.
    • Lost Updates : İki kullanıcı aynı veri üzerinde işlem yapmak istesin. Birinci kullanıcı veriyi görüntülesin, ardından ikinci kullanıcı aynı veriyi görüntülesin. İkisi de veri üzerinde değişiklik yapsın, ve kaydetmek istesin. Böyle bir durumda, kaydetme işlemini hangi kullanıcı önce yaparsa, diğer kullanıcı onun verisini ezecektir. Başka bir deyişle, önce kaydedenin güncellemesi kaybolacaktır. Bu durum Lost Update olarak adlandırılır.
    • Blocking : Bir kullanıcı, başka bir kullanıcının ihtiyacı olan veriye kilit koyarsa, ikinci kullanıcı engellenir. Bu durum Blocking olarak adlandırılır.
    • Deadlock : İki kullanıcı birbirinin ihtiyacı olan veriyi kilitlemişse, deadlock oluşur. Oracle veritabanında deadlock o kadar az gerçekleşir ki bu durum için bir hata üretilir.
    • Lock Escalation : Bir tablo üzerinde çok sayıda satır bazında kilit varsa, o tablonun tamamına kilit koyulmasına Lock Escalation denir. Oracle Lock Escalation yapmaz. Çünkü satır bazında kilitleme maliyeti Oracle’da mevcut değildir ve Lock Escalation’a gerek yoktur.
  • DML Locks, SELECT, UPDATE, DELETE ve INSERT işlemlerinde kullanılan kilitlerdir. TX ve TM olarak iki tiptedir. TX (Transaction Lock), bir transaction başladığında oluşur ve transaction sonlanana kadar üzerinde çalışılan veriyi korur. Üzerinde çalışılan her satır bir TX kilidine sahiptir. Bu maliyetli bir işlem gibi görülebilir ancak Oracle satır bazındaki kilitleri ayrı bir veri yapısında değil satırların fiziksel olarak ait oldukları bloklarda saklar, böylece satır bazında kilitleme işlemi bir overhead getirmez. TM kilitleri ise tablo bazındadır; üzerinde çalışılan bir tablonun yapısının değiştirilmesini engellemekten sorumludur.
  • DDL Locks, DDL işlemlerinde (CREATE, ALTER vb.) nesnelere koyulan kilitlerdir. DDL işlemleri her zaman COMMIT edilir, bu akılda tutulması gereken önemli bir bilgidir. Bir UPDATE işlemini takip eden bir DDL işlemi, o UPDATE işlemini de COMMIT edecektir.
  • Latch’ler, çok kısa sürelerle bir veri üzerinde tutulan kilitlerdir, örneğin bellekteki bir veriyi güncellerken başkalarının güncellemesini engellemek için kullanılır.
  • Transaction’lar için belli Isolation Levels vardır. Bu seviyeler, transaction’ın nasıl davranacağını belirler ve 3 adet kavram üzerinden incelenir:
    • Dirty Read : Bir başkasının değiştirdiği ancak henüz COMMIT etmediği veriyi okumak. COMMIT edilmemiş veri kirlidir ve her zaman ROLLBACK edilme ihtimali vardır.
    • Non-Repeatable Read : Bir kere okunan satır tekrar okumak istendiğinde o satırın değişmiş olabileceği anlamına gelir.
    • Phantom Read : Çalıştırılan bir sorgu tekrar çalıştırıldığında bir önceki veriye fazladan satırlar eklenmiş olma durumu.
  • Read Uncommited : Bu Isolation Level, SQL standardında bir başlangıç noktası olarak düşünülmüştür ve dirty read’lere izin vermektedir. Oracle bu Isolation Level ile çalışmaz, zaten varsayılan olarak multi-versioning uygulandığı için dirty read diye bir şey söz konusu değildir.
  • Read Commited : Bu seviyede dirty read engellenmektedir. Non-repeatable Read ve Phantom Read olabilir. En sık kullanılan seviyedir.
  • Repeatable Read : Bu seviye şunu söyler; sorgumun sonucu zamanda belli bir ana göre gelsin. Bunu gerçeklemek için shared read lock yapısı kullanılabilir, ancak Oracle bunu kullanmaz. Bu seviye Oracle’da bulunmamaktadır.
  • Serializable : Bu seviye, veritabanını bir noktada dondurur ve transaction’lar o ana göre çalışır. Karıştırılmaması gereken nokta; bu seviye transaction’ların birbirini bekleyerek ardı ardına çalışacağını söylemez. Sadece veritabanını bir noktada dondurur, ve sonuçları o noktaya göre döndürür. Veritabanının donduğu andan itibaren değişmiş olan bir satırı tekrar değiştirmeye kalkarsak, hata alırız.
Etiketler , , ,

Eğitim Notları – 3

TTECH’deki ikinci haftanın sonunda, Deniz Halıcıoğlu tarafından Oracle Architecture konulu bir eğitim aldık. Eğitimde aldığım notlar ve Expert Oracle kitabından faydalanarak öğrendiklerim aşağıdaki gibidir.

  • Database ve Instance kavramları birbiri yerine kullanılsalar da aslında farklı kavramlardır. Database, fiziksel dosyalardan oluşur, Instance ise prosesler ve SGA’dan oluşur. SGA’yı bütün Oracle proseslerinin erişebildiği bir bellek bölgesi olarak düşünebiliriz. Yani basit olarak, Instance daha soyut bir kavramdır. Bir Database’i birden çok instance kullanabilir ancak tersi geçerli değildir; bir Instance en fazla bir Database’e bağlı olabilir.
  • Dedicated Server modunda çalışılıyorsa, servera clienttan gelen her bağlantı isteği için bir proses oluşturulur ve bağlantı ölene kadar client bu proses üzerinden isteklerini bildirir. Adı üstünde, dedicated. Ancak bazı sistemler, onbinlerce kullanıcıya hizmet vermek durumunda olabilir. Bu noktada işletim sisteminin her client için bir dedicated proses sunması, çok fazla overhead getirir. Bu karakterdeki sistemlerde, MTS (Multi-Threaded Server) modunda çalışılır. MTS modunda her client için bir dedicated server yerine, ortak kullanılabilen shared server prosesleri oluşturulur. Oluşturulan bu havuzdaki proses sayısı daha azdır, yani daha kolay yönetilebilir. Dedicated Server modunda client direkt olarak prosesle konuşur, ancak MTS modunda arada bir dispatcher vardır. Dispatcher, clienttan gelen istekleri kuyruğa koyar ve shared server prosesleri işleri bittikçe bu kuyruktan yeni istek alır. İşini bitiren shared server ise cevabı ikinci bir kuyruğa koyar, ve dispatcher bu kuyruktan cevabı alıp clienta iletir.
  • Block, en küçük fiziksel veridir. Extend ise blocklardan oluşur ve bellekteki kesintisiz bir alanı ifade eder. Segment, bir veya daha çok extend’den oluşur ve veritabanında yer işgal eden herşey bir segmenttedir. Tablespace ise segmentlerden oluşan bir yapıdır. Bir segment en fazla bir tablespace’e ait olabilir. Bütün bu veri, Data File’larda tutulmaktadır. Bir segment’in extend’leri farklı data file’larda bulunabilir. Data file kavramı ile geliştiriciler olarak ilgilenmeyiz, Oracle bunu kendisi yönetmektedir. Sonuç olarak şöyle bir yapı ortaya çıkmakta:
Table Space > Segment > Extend > Block
Etiketler , , , , , , ,

Eğitim Notları – 2

Pazartesi sabah geldiğimizde departmanlarımıza dağıldık. Benimle birlikte aynı takımda çalışacak olan diğer stajyerlerle birlikte bizler için hazırlanan bilgisayarları kendi isteğimize göre ayarlamaya çalıştık. Çalışmaya başlayabilmek için kurmamız gereken uygulamaları ve erişim haklarımızı, bilgi işlem çalışanları ile birlikte ayarladık ve çalışma ortamımızı hazırlamış olduk.

Aynı gün Fuat Sungur tarafından “Developing Successful Oracle Applications” konulu bir eğitim aldık. Bu eğitimde Oracle üzerinde uygulama geliştirirken dikkat etmemiz gereken noktalar ve problemlere nasıl yaklaşmamız gerektiği üzerine tartıştık. Bu eğitimde aldığım notlar aşağıdaki gibidir:

  • Bind variable kavramı sorguların performansı açısından önemlidir. Bir sorgu yapıldığında, Oracle sorguyu parse etmek, belli bir execution plan oluşturmak gibi işlemler yapar. Bu işlemleri saklar ve aynı sorgu tekrar geldiğinde işlemleri tekrarlamaz. Bu süreç aslında şuna benzer; bir C programını derleyip çalıştırılabilir dosyayı oluşturduğumuzu düşünelim. Çalıştırılabilir dosya oluştuktan sonra kaynak koda ihtiyaç duymadan program tekrar tekrar çalıştırılabilir. Oracle’da benzer şekilde sorguların derlenmiş halini saklar ve tekrar tekrar çalıştırır. Ancak burada bir problem vardır.
SELECT * FROM EMPLOYEES WHERE employeeID = 100;
SELECT * FROM EMPLOYEES WHERE employeeID = 101;

Çok benzer iki sorgu gibi gözüken bu cümleler çalıştırıldığında, her biri ayrı ayrı parse edilir. Çünkü aslında bu iki sorgu, birbirinden farklıdır. Bu da zaman kaybı demektir. Bu zaman kaybını engellemek için, bind variable kullanılır. Aşağıdaki iki örnek, zaman farkının ne kadar fazla olduğunu göstermektedir:

CREATE OR REPLACE PROCEDURE with_binding IS
    TYPE rc IS REF CURSOR;
    l_rc    rc;
    l_dummy all_objects.object_name%TYPE;
    l_start NUMBER DEFAULT dbms_utility.get_time;
BEGIN
    FOR i IN 1 .. 1000 LOOP
        OPEN l_rc FOR 'select object_name from all_objects '  ||
  'where object_id = :X'
        USING i;
        FETCH l_rc
        INTO l_dummy;
        CLOSE l_rc;
    END LOOP;
    dbms_output.put_line(round((dbms_utility.get_time - l_start) / 100, 2)
 || ' seconds...');
END with_binding;
/
CREATE OR REPLACE PROCEDURE without_binding IS
    TYPE rc IS REF CURSOR;
    l_rc    rc;
    l_dummy all_objects.object_name%TYPE;
    l_start NUMBER DEFAULT dbms_utility.get_time;
BEGIN
    FOR i IN 1 .. 1000 LOOP
        OPEN l_rc FOR 'select object_name from all_objects
where object_id = ' || i;
        FETCH l_rc
        INTO l_dummy;
        CLOSE l_rc;
END LOOP;
    dbms_output.put_line(round((dbms_utility.get_time - l_start) / 100, 2)
 || ' seconds...');

END without_binding;

Bu rutinler verildiğinde, aşağıdaki kod çalıştırılabilir. Sonuç, aradaki devasa farkı göstermektedir:

BEGIN
    with_binding;
    without_binding;
END;
----------------------
,05 seconds...
9,86 seconds...
  • Oracle veritabanındaki iki önemli konsept, read-consistent queries ve non-blocking queries olarak bilinir. Read-consistent queries, zamanın belli bir anına göre tutarlı cevaplar döndüren sorgulardır, non-blocking queries ise yazıcılar tarafından engellenmeyen sorguları temsil eder. Yazıcı ve okuyucuların birbirini engellememesi önemlidir. Yazıcılar okuyucuları engellemezse, bir yazma işlemi sürerken veri okunabilir. Okuyucular yazıcıları engellemezse de, bir veri okunurken yazma işlemi yapılabilir. Hem bu özellikleri sağlayıp, hem de veri tutarlılığını sağlamak için, multi-versioning kavramından yararlanılır. t=0 anında bir sorgu isteğinde bulunalım ve bu sorgu t=5 anına kadar sürecek olsun. t=3 anında bir güncelleme isteği, bizim sorgumuzun t<3 iken okuduğu veya t>3 iken okumak istediği veriyi değiştirmek istesin. Eğer yazıcılar okuyucuları beklemez diyorsak, bu mümkün olmalı. Peki bizim sorgumuzun tutarlılığı nasıl sağlanacak? Bu noktada multi-versioning kavramı ortaya çıkıyor. 0<t<5 süresince oluşacak herhangi bir değişiklik, bizim sorgumuzu ilgilendirmemekte. Bizim sorgumuz, her zaman verinin t=0 anındaki haline bakmakta, bu sayede tutarlılık sağlanmaktadır.
  • Kullanılan veritabanının sunduklarını iyi bilmek gerekir. Database Independent bir uygulama geliştireceğim diye, veritabanının kendine özel ama çok faydalı özelliklerini kullanmamak saçma olur. Thomas Kyte’ın sunumundan alıntı yapmak gerekirse, “Problemleri mümkün olduğunca basit bir şekilde ve Oracle’ın sunduğu işlevselliği kullanarak çözün. Bu özellikler için çok para ödediniz.”.
Etiketler , , ,
Takip Et

Her yeni yazı için posta kutunuza gönderim alın.