Merhaba,
Son zamanlarda Oracle Golden Gate ile yaşadığım bir sorunu paylaşmak istiyorum sizlerle.
Bu sorunda maalesef başka çeşitli ürünlerde de yaşayabildiğim hatalı hata mesajı sorununu yaşadım. Tabii ki karşıma çıkan hata mesajının çok yanıltıcı olduğunu, sorunu tespit edince anladım.
Hata mesajı şuydu:
"WARNING OGG-00091 VAM Client Report <[TruncMgr::Timer] Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication. Error (-2147217900): Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication."
Bu hatayı, kaynak sunucuda Extract'ı başlattıktan kısa bir süre sonra Extract'ın Report dosyasında (dirrpt klasöründeki) görüyordum. Bununla birlikte Extract ABENDED veya STOPPED durumlarına gelmiyor, hâlâ RUNNING görünüyordu.
Sorunu yeniden oluşturmak için şöyle bir yol izleyebilirsiniz:
- Yeni bir Extract ekleyin (ADD EXTRACT).
- Extract'ın parametre dosyasını ihtiyacınıza göre düzenleyin, yalnız ODBC adını başka bir veritabanına giden bir ODBC adı olarak verin (evet, bizim durumumuzdaki sorun buydu). Örneğin Extract işlemini yapacağınız veritabanı XXX, ama o Extract'ın parametre dosyasında kullanılan ODBC'deki veritabanı YYY.
- Başarılı bir şekilde DBLOGIN SOURCEDB ile o ODBC'ye bağlanın.
- Yine başarılı bir şekilde ADD TRANDATA ile, Extended Logging'i etkinleştirmek istediğiniz tablolar bu işlemi gerçekleştirin.
- Extract'ı çalıştırın.
Yukarıdaki işlemleri gerçekleştirdikten sonra Extract'ın Report dosyasında bu hatayı göreceksiniz.
Biz bu hata konusunda Oracle Support ile birlikte çalıştık ve neredeyse 1 ay sonra, o da kazayla başka bir şeye bakarken sorunun bu olduğunu gördük. Gördüğünüz gibi hata mesajının sorunun kendisiyle doğrudan hiçbir ilgisi yok. Hata mesajına bakınca gidip CDC'yi veya başka bilumum şeyi kontrol etmek geliyor akla, ama ODBC adını Extract parametre dosyasında doğru mu yanlış mı yazdığınızı kontrol etmek gelmiyor maalesef.
Kolay gelsin,
Ekrem
6 Temmuz 2011 Çarşamba
25 Mayıs 2011 Çarşamba
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
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
27 Nisan 2011 Çarşamba
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.
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.
5 Nisan 2011 Salı
Ö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
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
3 Nisan 2011 Pazar
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
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
Kaydol:
Kayıtlar (Atom)