More VRP

Uzun bir aradan sonra, henüz bugün tanımını aldığımız More VRP yazılımından bahsetmek istiyorum sizlere. Bu uygulamadan size, bize sunumu yapan Michael Rozhkovsky gibi ayrıntılı bir şekilde bahsetmeyeceğim tabii ki. Fakat Veritabanı Yöneticiliği yapan ve kritik noktalarda görevli kişilerin bu konuda bilgisi olmasını istediğim için bu uygulamadan kısa da olsa bahsetmek istedim.

More VRP, temel olarak bir Kriz Yönetim uygulaması ve yine temel olarak yaptığı şey ise İşlem Yönetimi (Transaction Management). Bu uygulamanın henüz piyasada bir eşi benzeri olmadığını da vurgulamak isterim, en azından firmanın bize verdiği bilgi bu yönde. Uygulamanın Türkiye'deki distribütörü ise Aktek Bilgi İletişim Tek. San. Tic. A.Ş.

Uygulamanın izleme modülüyle, sistemde çalışan tüm işlemleri görebiliyorsunuz. CPU, IO masraflarını ve bu işlemlere ait birçok ayrıntıyı anlık bilgilerle izleyebiliyorsunuz. Ayrıca bu arayüzü birçok grafiklerle de süslemişler.

Bu bahsettiğim şeyler elbette bu uygulamayı eşsiz yapan bir özellik değil, bu uygulamayı eşsiz yapan ve patenti sadece bu firmada bulunan ve tabii ki bizi de büyüleyen özelliği ise, seçtiğiniz sorguların CPU ve IO masraflarını anlık olarak daraltabilmeniz.

Bir örnek vermek gerekirse: örneğin ortamınızda iki tane sorgu çalışıyor, biri CPU kaynağının %30'unu, diğeri de %50'sini harcıyor diyelim. Bu sorgulardan herhangi birini seçerek, o anda harcıyor olduğu kaynakların değerini %30'dan %10'a anlık olarak çekebiliyorsunuz. Bu işlem saniyeler içerisinde gerçekleşiyor. Dediğim gibi, bu teknolojinin patenti sadece merkezi İsrail'de olan bu firmaya ait.

Uygulamanın Console denilen bölümü ayrı bir sunucuya kuruluyor. Bu sunucu öyle ahım şahım bir şey olmak zorunda değil. 4GB RAM'i olan PC gibi bir makine olabilir. Console ise takip edilecek sunucularla bir Agent vasıtasıyla haberleşiyor. Agent ise bir CPU'nun sadece %0.5'i kadar kaynak tüketiyor en fazla. Çünkü tüm işi yapan Console. Bu yüzden üretim sunucularınıza ek yük getirecek bir durum da söz konusu değil.

Ayrıca sistem Cluster\RAC yapılarını da destekliyor. Failover anlarında geçişler otomatik ve yöneticilere hissettirilmeden yapılıyor. RDBMS tarafındaki kesintilerin sonuna kadar hissedilmesi ise tabii ki ayrı bir konu.

Yine bize verilen bilgilere göre bu uygulamayı İsrail'de çok büyük Telekom ve Banka firmaları da dahil 400 firma kullanıyor, dünya çapında ise 600 firma. Önceden Oracle Golden Gate ile ilgili böyle bir facia yaşadığımız için haliyle hemen Türkiye'de bu ürünü SQL Server üretim ortamlarında kullanan olup olmadığını sordum, Aktek'ten arkadaşlar bana olumsuz yanıt verdiler. Onlar da 1 senedir bu uygulamayı Türkiye'de temsil ediyorlarmış ve bu süreçte birçok firmada POC (Proff of Concept) çalışması yapmışlar, fakat henüz üretim ortamında ürünü kullanan yok.

Açıkçası ürün benim oldukça ilgimi çekti. Kriz durumlarında sorun yaratan sorguları, SP'leri vb. dizginleyebilmek ve sorunu çözünceye kadar bu işlemleri belli sınırlar içinde tutabilmek oldukça mantıklı ve makul. Sorun çözülünce sınırlamaları kaldırmak da çok kolay.

Tabii ki ürünün başka birçok özellikleri de var, örneğin ne kadar isterseniz o kadar geçmişe dönük sorguları ve masraflarını saklayabilmek, yanyana sürüm yükseltme (Side by Side Upgrade) sonrasında iki sunucuyu karşılaştırıp kazanım ve kayıpları gösterebilmek, bir gün öncesi ve sonrası veya başka tarih aralıklarında gerçekleşen sistem değişikliklerini veritabanı bazında listeleyebilmek, değişen Execution Plan'ları çok rahat bir şekilde belirleyebilmek gibi...

Son olarak şunu söylemeliyim ki ürün sadece SQL Server ile çalışmıyor. Oracle, DB2 gibi RDBMS'leri de destekliyor. Ayrıca OS olarak da Platform Bağımsız bir ürün.

SQL Server'a özel olarak ise, SQL Server'ın sadece 2005 ve 2008 özelliklerini destekliyor şu anda. SQL Server 2008 R2 desteği henüz yok. SQL Server 2000 için ise Microsoft ile iş birliği yapmak istemişler, fakat Microsoft SQL Server 2000'i biz bile desteklemiyoruz artık demiş, gerisini siz düşünün.

Umarım ürün hakkında az çok fikir edinebilmenize yardımcı olur bu bilgiler.

Ekrem Önsoy

Could not load package "UpdatePreApprovalCampaignSSIS" because of error 0xC0014062.

HATA: Could not load package "paketin adı" because of error 0xC0014062.
Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80040E4D (Login failed for user 'kullanıcı adı'.). The SQL statement that was issued has failed.

AÇIKLAMA:
Bir SSIS paketi yüklemeye çalıştığınızda böyle bir hata ile karşılaşabilirsiniz.

Çözüm:
Kullanıcının ("Login failed for user" bölünde yazan kullanıcının) ilgili sunucuda Login'i ve yeterli hakları bulunduğundan emin olun. Örneğin "msdb" veritabanının altındaki SSIS rollerini de kontrol edebilirsiniz.

ÖNEMLİ: SQL Server 2008 Online Index Rebuild'deki davranış değişikliği!

Arkadaşlar dün yeni bir şey daha öğrenmiş olduk, fakat bu öğrendiğimiz şeyi geç öğrenmenin bedelini de ödedik.

SQL Server 2008'e geçtiğimizden beri Index bakımı yapılan zamanlarda Transaction Log yedeklerimizin eskiye nazaran çok büyüdüğünü gözlemledik ve Transaction Log yedeklerimizi aldığımız disk artık yetmez oldu. Acilen ekstra disk talep ederek bu sorunu atlattık, ama anlayamadığımız şey neden birden böyle bir sorunla karşılaştığımızdı. Kayıt sayılarında böyle ani bir artık beklenecek bir durum yoktu ortada, en azından işlemler açısından.

Sağolsun MS PFE'mizin bize ilgili KB'yi iletmesiyle sorun anlaşıldı. SQL Server 2008'den itibaren, Online Index Rebuild işlemleri Transaction Log dosyasına artık tam olarak işleniyormuş. SQL Server 2005'te bu işlem asgari seviyede yapılıyormuş. Bu sorunu kritik sistemlerimizi SQL Server 2008'e yükseltince farkettik, çünkü malum kritik sistemler en fazla kayıdın oluştuğu sistemler ve bu nedenle de Transaction Log'un en çok kullanıldığı, en büyük Transaction Log yedeklerinin oluştuğu sistemler.

Daha fazla bilgi için ilgili KB'yi incelemek isteyebilirsiniz: http://support.microsoft.com/kb/2407439

2011-2012 Microsoft SQL Server MVP Ödülü, 3. kere =)

Selam arkadaşlar,

Bugün 3. kere Microsoft SQL Server MVP ödülünü kazandığımı öğrendim... Umarım bu sayede daha çok şey öğrenebilir ve sizlere de olabildiğince aktarabilirim.

Sevgiler,
Ekrem Önsoy

Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number c

HATA:
Package migration from version 3 to version 2 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.

Açıklama:
Bir SSIS paketini doğrudan veya dolaylı olarak (örneğin bir toplu işlem dosyası (*.bat) ile) "dtexec" uygulaması kullanarak çalıştırmak isterseniz böyle bir hata ile karşılaşabilirsiniz. Örneğin ben bu sorunla karşılaştığımda, SSIS paketleri SQL Server 2008 versiyonuyla uyumluydu; paketler başka bir sunucudaydı ve paketler toplu işlem dosyaları ile çalıştırılıyordu. Paketler ise başka bir sunucudan UNC yolu kullanılarak (örn: \\...\...\...) çalıştırılıyordu. Yani çalıştırılan "dtexec" uygulaması aslında toplu işlem dosyalarına hangi makineden ulaşılıyorsa o makinedeki "dtexec" uygulaması kullanılmış oluyordu, SSIS paketlerinin bulunduğu sunucudaki "dtexec" değil.

Sorunu araştırırken şunu farkettim, operatörün bağlandığı makinede hem SQL Server 2005 hem de SQL Server 2008 kuruluydu ve operatör toplu işlem dosyasını çalıştırdığında aslında SQL Server 2005 versiyon olan "dtexec" uygulaması çalıştırılıyordu ve "eski yeniyi tanımaz" kuralına uygun olarak 2008 versiyon SSIS paketlerini tanımadığından yukarıdaki hatayı veriyordu.

Windows Environment Variables'ı kontrol ettiğimde SQL Server 2005 yolunun 2008 yolundan önce tanımlandığını gördüm, yani bir uygulama çalıştırılacağı zaman öncelikle 2005'in yollarında aranıyordu uygulama ve "dtexec" uygulaması SQL Server 2005'te de 2008'de de aynı isimle olduğundan dolayı 2005 versiyonu çalıştırılıyordu.

ÇÖZÜM:
Sorunu tespit ettiğimde geçici çözüm olarak SQL Server 2005'in "dtexec" uygulamasının adını "dtexec_" olarak değiştirdim ve artık varsayılan olarak SQL Server 2008'in "dtexec" uygulaması çalıştırılıyordu. Kalıcı çözüm olarak ise şayet gerekmiyorsa SQL Server 2005 tamamen kaldırılabilir (uninstallation). Şayet iki versiyona da ihtiyaç varsa yine ilk çözümde olduğu gibi dosya adı değiştirilebilir.