9 Şubat 2009 Pazartesi

SQL Server Instance' ına Sistem Yöneticisi Olarak Giremediğinizde

Merhaba arkadaşlar,

Olmaz demeyin, gerçekten olduğuna kaç kere şahit oldum. Kullanıcılar bazen farkında olmadan tüm System Administrator yetkisine sahip Login' leri silebiliyorlar ve bunun sonucunda da SQL Server Instance' larına yönetici olarak bağlanamıyorlar.

Bu gibi durumlarda genellikle başvurulan yöntem, SQL Server Instance' ının sistemden kaldırılması, yeni bir SQL Server Instance' ının kurulması ve veritabanlarının yeni Instance' a bağlanması oluyor. Bu şekilde, eğer sistem veritabanlarının (master, msdb gibi) yedekleri yoksa, tüm Maintanence Plan' lar, Job' lar, Login' ler vb. yok oluyor. Zaten bu sistem veritabanlarının yedekleri olsa dahi, Login bilgilerinin saklandığı "master" veritabanında da "sysadmin" rolüne üye bir Login bulunmayabilir. Ayrıca bu, çok zahmetli ve zaman alıcı bir iş olacaktır.

Bunun yerine aşağıdaki yöntemi uygulamanızı tavsiye ederim:

- Sisteme Yerel Yöneticiler (Local Administrators) Windows grubuna üye bir kullanıcıyla oturum açın,
- SQL Server Intance' ınızı Tek Kullanıcılı Mod (Single User Mode)' da açın, bunun için:
- SQL Server Configuration Manager' ı açın,
- SQL Server 2005 Services isimli düğüme tıklayın ve sağdaki pencereden ilgili SQL Server Instance' ınızın
özelliklerine (Properties) gidin,
- "Advanced" sekmesinde, "Startup Parameters" özelliğini bulun ve oraya, Resim-1' deki gibi "-m" parametresini
ekleyin.
- Parametre ekleme işleminden sonra SQL Server Instance' ınızın Veritabanı Motoru (Database Engine) servisini
durdurup yeniden başlatmanız gerekiyor.

Resim-1


Burada dikkat etmeniz gereken şey ise, SQL Server Instance' ınızın artık sadece bir kullanıcı kabul edeceğidir. Bu yüzden ilgili SQL Server Instance' ına ait SQL Server Agent servisinin çalışmadığından emin olun.

Tüm bu gereklilikleri yerine getirdikten sonra, SQL Server Management Studio (SSMS)' yu açın ve Query Editor' ü kullanarak ilgili SQL Server Instance' ınıza bağlanın. Object Explorer' dan değil, Query Editor' den bağlandığınıza emin olun, çünkü Object Explorer' dan bağlandığınızda sistemi eski haline getirmek için Login değişiklikleri yapmak istediğinizde SSMS SQL Server Instance' ınıza birden fazla bağlantı kurmak isteyecektir ve sistem de bunu kabul edemeyeceği için bu da hataya neden olacaktır.

SSMS' i açtıktan sonra yeni bir Query Editor penceresi açmak için SSMS' in sol üst köşesinde bulunan New Query düğmesine tıklayabilir veya File->New->Database Engine Query menüsünü kullanabilirsiniz.

Query Editor' de yeni bir sorgulama penceresi açtıktan sonra System Administrator haklarına sahip yeni bir kullanıcı oluşturmak için aşağıdaki komutları kendi ortamınıza uyarlayarak çalıştırmanız gerekiyor:

-- Yeni bir Windows Login oluşturma:
CREATE LOGIN [Test6\Administrator] FROM WINDOWS

-- Oluşturulan Login' i "sysadmin" Server Fixed Role' üne üye yapma:
EXEC sp_addsrvrolemember 'test6\Administrator', 'sysadmin';

Yeni Login oluşturma hakkında daha fazla bilgi için aşağıdaki adrese gözatın:
http://msdn.microsoft.com/en-us/library/ms189751(SQL.90).aspx

sp_addsrvrolemember Sistem Stored Procedure' ü için ise aşağıdaki adresi inceleyebilirsiniz:
http://msdn.microsoft.com/en-us/library/ms186320.aspx

Yeni Login de oluşturulup gerekli haklar verildikten sonra SQL Server Instance' ınıza başlangıç parametresi olaran eklediğiniz "-m" parametresini yukarıda izlediğiniz yolu izleyerek çıkarıp, SQL Server Instance' ınızın Database Engine servisini tekrar başlatmanız gerekir ve artık oluşturduğunuz Login ile SQL Server Instance' ınıza Sistem Yöneticisi olarak bağlanabilirsiniz!



Ekrem Önsoy

Eksik Index' ler ve DMV' ler

ÖNEMLİ NOT:
Bu sayfada tablolar düzgün görünmüyor, bu nedenle bu yazının aynısını aşağıdaki adresten okumanızı tavsiye ederim:
http://www.ekremonsoy.net/makaleler/sql/eksik_indexler/eksik_indexler.aspx

Merhaba arkadaşlar,

Muhtemelen çoğunuzun da bildiği gibi, SQL Server 2005 ile birlikte Dynamic Management Views (DMV) ve Dynamic Management Functions (DMF) diye adlandırılan kullanımı kolay, pratik ve işlevsel olan araçlar da kullanımımıza sunuldu.

Bu yazımda, tüm DMV veya DMF' lerden bahsetmeyeceğim; hatta sadece DMV' lerden ve yazının başlığından da anlaşılacağı üzere sadece Index' ler konusunda kullanılabilecek 3 tane DMV' den bahsedeceğim sizlere. Bu DMV ler:

- sys.dm_db_missing_index_group_stats

- sys.dm_db_missing_index_groups

- sys.dm_db_missing_index_details

Query Optimizer bir Sorgu Planı (Query Plan) oluşturduğunda, bu plan için en iyi olabilecek Index' leri analiz eder. Eğer kullanılabilecek en uygun Index' ler oluşturulmamışsa, o zaman Query Optimizer elindeki yapıyla oluşturabileceği en uygun planı oluşturur ama yaptığı analiz sonucunda uygun bulduğu en iyi Index' ler hakkındaki bilgiyi de saklar. Yukarıda listelediğim DMV' ler ile de Query Optimizer' ın kaydettiği bu bilgilere ulaşabiliriz ve bu bilgileri yorumlayarak, sistemimize en uygun olabilecek Index' leri kendimiz oluşturabiliriz. Bu DMV' ler bize ihtiyacımız olan çoğu bilgiyi sağlıyorlar. Meselâ hangi tabloda, hangi alanların kullanıcılarca çok sorgulandığı ve eğer xxx alanında xxx alanlarını kapsayan bir Index olması durumunda yapılan sorguların % kaç performans kazanabileceğine kadar...



Bu DMV de neyin nesi?

DMV' ler size, SQL Server sunucunuzun sağlıklı çalışabilirliğini gözlemleyebileceğiniz, sorunları teşhis edebileceğiniz ve performans düzenlemeleri yapabileceğiniz bilgileri verir.

DMV' leri kullanırken sadece isimlerini vererek kullanamazsınız, en azından Schema isimlerini de belirtmelisiniz. Bu nesnelerin tümü, "sys" isimli Schema' nın altındadır ve hepsinin de isimleri "dm_" karakterleriyle başlar. Örneğin: sys.dm_db_missing_index_group_stats gibi.

Bu DMV' den dönen sonuçlar, veritabanlarına yapılan her sorgudan sonra güncellenir. Bu yazıda değindiğim DMV' lerden gelecek bilgilerin, SQL Server Instance' ının servisinin yeniden başlatılması halinde sıfırlanacağını dikkate almanız gerekiyor. Çünkü servis yeniden başlatıldıktan sonra kısa zamanda büyük ihtimalle henüz sağlıklı bir Index oluşturma kararına varabileceğiniz kadar veri birikmiş olmayacaktır. Bu tür analizleri yaparken yeteri kadar verinin biriktiğinden emin olmalısınız.

DMV' leri aynen normal View' ler gibi sorgulayabilirsiniz, örneğin:

SELECT TOP 10 *

FROM sys.dm_db_missing_index_group_stats;

GO

Bazı DMV' ler doğrudan sorgulanamaz ve parametre ister, bunu da not etmekte fayda var.

Ayrıca, DMV ve DMF' lerin iki türü olduğunu da belirtmek lâzım. Bunlar:

- Sunucu düzeyinde çalışan DMV ve DMF' ler. Bu düzeydeki bir DMV ve DMF' i çalıştırmak için kullanıcının sunucu düzeyinde VIEW SERVER STATE iznine sahip olması gerekir. *

- Veritabanı düzeyinde çalışan DMV ve DMF' lerdir. Bu düzeydeki bir DMV ve DMF' i çalıştırmak için ise kullanıcının VIEW DATABASE STATE iznine haiz olması gerekmektedir. *

* Bununla birlikte, elbette ilgili nesne için de SELECT izinlerinin bulunması gerekiyor. Bu yazıda değindiğim dört DMV de, "master" sistem veritabanındadır.

sys.dm_db_missing_index_group_stats

Eksik Index grupları hakkında bilgi verir. Aşağıda, bu DMV' nin içerdiği ve benim en çok işe yarayacağını düşündüğüm alanları ve bu alanların açıklamalarını vereceğim.
Alan adı Veri tipi Açıklama
group_handle int Bir eksik Index grubunu tanımlar.
unique_compiles bigint Bu Index grubundan yararlanabilecek derlenen ve tekrarlı derlenen sorgu sayısı.
user_seeks bigint Gruptaki Index oluşturulsaydı, bu alanda belirtilen sorgu sayısı kadar sorgu için bu Index kullanılabilecekti. (Arama işlemi için) *
user_scans bigint Gruptaki Index oluşturulsaydı, bu alanda belirtilen sorgu sayısı kadar sorgu için bu Index kullanılabilecekti. (Tarama işlemi için) *
avg_total_user_cost float Gruptaki Index' in kullanılması halinde, yapılacak sorgulamalar için ortalama olarak düşürülecek maliyet miktarı.
avg_user_impact float Bu Index' in oluşturulmasıyla kullanıcı sorgularının edinilebileceği ortalama yüzde miktarı. Bu değer şu anlama geliyor: eğer bu Index grubu oluşturulmuş olsaydı, sorgunun maliyeti bu yüzde kadar düşürülebilirdi.

* Bu alanlarda belirtilen Seek ve Scan işlemleri, Index Seek ve Index Scan işlemleridir. Bu işlemler başlı başına ayrı bir konu olduğu için bu yazımda değinemem. Sadece kavramların havada kalmaması için bir not koymak istedim.

** Diğer alanlar hakkında da bilgi almak istiyorsanız, Books Online' daki ilgili sayfayı ziyaret edebilirsiniz: http://msdn.microsoft.com/en-us/library/ms345421(SQL.90).aspx

Aşağıdaki örnekte, kullanıcı sorgulamaları için en yüksek performans artışı sağlayabilecek 10 eksik Index' i buluyoruz:

SELECT s.group_handle, s.avg_total_user_cost , s.avg_user_impact , s.last_user_seek , s.unique_compiles
FROM sys.dm_db_missing_index_group_stats s
ORDER BY s.avg_user_impact desc

Bu sorguyu çalıştırdığınızda alacağınız sonuç tek başına yeterli olmayacaktır. Bu sorguyla birlikte diğer "missing_index" DMV' lerini de kullanmamız gerekecek, böylece hangi alanları kullanarak Index oluşturabileceğimiz bilgisini de edinebileceğiz.



sys.dm_db_missing_index_groups

Belli bir Index grubunda hangi eksik Index' lerin bulunduğu hakkında bilgi verir. Aşağıda, bu DMV' nin içerdiği alanları ve bu alanların açıklamalarını vereceğim.
Alan adı Veri tipi Açıklama
index_group_handle int Bir eksik Index grubunu tanımlar.
index_handle int index_group_handle ile belirlenen gruptaki eksik Index' leri belirler.

Bu DMV için örnek yapmıyorum, çünkü tek başına kullanımı anlamlı hiçbir şey vermeyecektir. Bu DMV dm_db_missing_index_group_stats ile dm_db_missing_index_details arasında köprü kurmak için kullanılabilir. Bir sonraki başlık olan dm_db_missing_index_details örneğinde göreceksiniz.



sys.dm_db_missing_index_details

Eksik Index hakkında ayrıntılı bilgi verir. Aşağıda, bu DMV' nin içerdiği alanları ve bu alanların açıklamalarını vereceğim.
Alan adı Veri tipi Açıklama
index_handle int Belli bir Index' i tanımlar. Tanımlama numarası sunucu çapında eşsizdir.
database_id smallint Eksik Index' in bulunduğu tablonun hangi veritabanında olduğunu tanımlar. Veritabanının ID' sini döndürecektir; eğer veritabanının adını görmek isterseniz o zaman bu alanı SELECT cümleciği içerisinde OBJECT_NAME(database_id) olarak tanımlayabilirsiniz.
object_id int Eksik Index' in hangi tabloda olduğunu tanımlar.
equality_columns nvarchar(4000) Eşitlik şartlarının bulunduğu ve virgüllerle ayrılmış alanların listesini verir. (Örn: tablo.alanAdı = değer)
inequality_columns nvarchar(4000) Eşitlik olmayan şartların bulunduğu ve virgüllerle ayrılmış alanların listesini verir. (Örn: tablo.alanAdı > değer)

"=" den başka tüm operatörler eşitlik olmayan şartlar listesine girer. Operatörler hakkına daha fazla bilgi almak için buraya tıklayın (İngilizce).
included_columns nvarchar(4000) Covering Index* oluşturmak için kullanılacak alanların listesini virgüllerle ayrılmış şekilde verir.
statement nvarchar(4000) Eksik Index' in bulunduğu tablonun adı.

* Özet: Covering Indexes \ Included Columns, SQL Server 2005 ile gelen bir yeniliktir. Özetlemek gerekirse, Key alan olarak bir Index' e en fazla 900 Byte' lık alan ekleyebilirsiniz. Bazı durumlarda bu değerden daha büyük alanları eklemek gerekebilir, işte SQL Server 2005 ile gelen Included Columns özelliği sayesinde artık Index' lere daha fazla alan ekleyebiliyoruz. Bu alanlara da Non-Key Alanlar deniyor. Bu konuda daha fazla bilgi için buraya tıklayın (İngilizce).

Bu DMV' yi tek başına kullanmak bayağı zahmetli olabilir. Bu nedenle ben daha ziyade önceki iki DMV ile birlikte hepsini kullanmayı tercih ediyorum. Meselâ aşağıdaki örneğe bakın:

SELECT d.* , s.avg_total_user_cost , s.avg_user_impact , s.last_user_seek ,s.unique_compiles
FROM sys.dm_db_missing_index_group_stats s , sys.dm_db_missing_index_groups g , sys.dm_db_missing_index_details d
WHERE s.group_handle = g.index_group_handle AND d.index_handle = g.index_handle order by s.avg_user_impact desc



Önemli Notlar

Yukarıda bahsettiğim DMV' lerden alacağınız eksik Index bilgileri sadece tablolarınıza karşı çalıştırılan SELECT sorgularından edinilmiştir. Yani bu DMV' ler tarafından verilen bilgilerin INSER\UPDATE ve DELETE işlemlerine ne gibi etkilerinin olacağı bilgisi yoktur. Bu nedenle bu DMV' lerden aldığınız bilgilere %100 güvenerek Index oluşturmamalısınız.

Benim size bu noktadaki tavsiyem dm_db_index_usage_stats DMV' sini kullanarak, oluşturduğunuz Index' lerin kullanımını da gözlemeniz. Eğer bu DMV ile aldığınız bilgilerde, oluşturduğunuz Index' lere karşı yapılan SEEK ve SCAN işlemleri UPDATE işlemlerinden daha az ise o zaman bu Index' in size çok faydalı olacağını söylemek yanlış olurdu.

dm_db_index_usage_stats' i çalıştırmak size zahmetli geliyorsa o zaman SQL Server Management Studio 2005 ile birlikte gelen raporları da kullanabilirsiniz. Meselâ SSMS' i açtıktan sonra bir veritabanının üzerinde farenin sağ tuşuna tıklayın, açılan menüden de Reports -> Standard Reports -> Index Usage Statistics' e tıkladığınızda dm_db_index_usage_stats DMV' si kullanılarak alınmış bir raporu görebilirsiniz. Bu rapordaki veriler ışığında da hangi Index' lerin ne kadar çok, hangilerinin ne kadar az kullanıldığını belirleyebilirsiniz.



Ekrem Önsoy

"Replication is skipping schema version logging because the systranschemas table is not present in database 'veritabani_ID'. This is an informational

MESAJ:
"Replication is skipping schema version logging because the systranschemas table is not present in database 'veritabani_ID'. This is an informational message only. No user action is required."

AÇIKLAMA:
Replication kurulu bir sisteminizde, Publication olarak kullandığınız fakat daha sonra bu Publication' ı kaldırdığınız bir veritabanınız için SQL Server Log dosyalarında böyle bir mesaj ile karşılaşabilirsiniz.

Hatta önceden Replication' a dahil olan fakat sonradan bu veritabanının Publication' ınını kaldırdığınız veritabanınızda bir değişiklik yapmaya kalktığınızda, bu veritabanının Replication' a dahil olduğunu söyleyen ve bu nedenle değişiklik yapmanızı engelleyen bir mesaj ile de karşılaşabilirsiniz.

Böyle durumlarda genellikle Publication doğru şekilde kaldırılmamış oluyor. Bu nedenle bu işlemi "sp_removedbreplication" sistem Stored Procedure' u ile yapabilirsiniz.

Örnek:
sp_removedbreplication 'veritabanı_adı'

Bu komut hakkında daha fazla bilgi için aşağıdaki sayfayı inceleyebilirsiniz:
http://msdn.microsoft.com/en-us/library/ms188734.aspx

"Autogrow of file in database was cancelled by user or timed out after milliseconds. Use ALTER DATABAS

MESAJ:
"Autogrow of file in database was cancelled by user or timed out after milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size."

AÇIKLAMA:
SQL Server Log dosyalarında sürekli olarak veya sık sık böyle bir mesaj görebilirsiniz. Bunun nedeni, veritabanınızı oluşturan dosyalardan olan veri dosyasının veya kayıt (log) dosyasının içerisinde yer olmadığından ve yeni kayıtları kabul etmeleri için yer gerektiğinden dolayı sürekli büyüme gereksinimlerinden kaynaklanıyordur.

Veri ve kayıt dosyalarında her zaman yeterli boşluk olmalıdır ki, böyle fiziksel dosya büyütme işlemlerine sık sık gerek kalmasın. Bu tür işlemler yapılırken kullanıcıların işlemleri bekletilir ve böylece kilitlenmeler, donmalar vs. yaşanır.

"One or more of the server network addresses lacks a fully qualified domain name (FQDN). Specify the FQDN for each server, and click Start Mirroring

HATA MESAJI:
"One or more of the server network addresses lacks a fully qualified domain name (FQDN). Specify the FQDN for each server, and click Start Mirroring again. The syntax for a fully-qualified TCP address is: TCP://.[.]:"

AÇIKLAMA:
SQL Server Management Studio' da, bir veritabanının Properties penceresindeki Mirror bölümünden Database Mirroring oluşturmaya çalışırken bu sorun ile karşılaşabilirsiniz.

ÇÖZÜM:
Sorun, Wizard' ın bir şekilde bilgisayar ismini çözememesinden kaynaklanıyor.

Meselâ iki tane farklı SQL Server Instance' ını aynı makine üstünde kurdunuz diyelim ve bu hata ile karşılaştınız. Bu sorunu çözmek için ilgili veritabanının Properties penceresindeki Mirror bölümünde bulunan Configure Security düğmesine tıklayıp Database Mirroring topolojisine dahil Instance' ların bağlantı ayarlarını yaptıktan sonra size Database Mirroring' i hemen başlatmak isteyip istemediğiniz sorulur. Siz hemen başlatmak istemeyeceksiniz, çünkü Principal ve Mirror bilgileri olarak bilgisayar isimleri yazıyor ve siz eğer bu hata ile karşılaşıyorsanız o zaman orada bilgisayar isimlerin yerine IP adreslerinin yazmasını isteyeceksiniz. Bu nedenle de hemen başlatmak istemediğinizi belirteceksiniz ve belirttiğim alanların yeniden düzenlenebilir olduğunu göreceksiniz.

O alanlara, ilgili bilgisayarların\sunucuların IP adreslerini yazın ve artık Start Mirroring düğmesine tıklayarak aynalama işleminizi mutlu bir şekilde başlatabilirsiniz.

"BACKUP LOG cannot be performed because there is no current database backup."

HATA MESAJI:
"BACKUP LOG cannot be performed because there is no current database backup."

AÇIKLAMA:
BACKUP LOG komutuyla bir veritabanının Transaction Log yedeğini almaya çalışırken böyle bir hata ile karşılaşabilirsiniz.

ÇÖZÜM:
Bunun nedeni, bu veritabanının henüz hiç tam yedeğinin (Full Backup) alınmamasıdır. BACKUP LOG ve BACKUP DATABASE ... WITH DIFFERENTIAL komutlarını çalıştırmadan önce bu işlemleri yapmaya çalıştığınız veritabanının tam ydeğini BACKUP DATABASE komutuyla almalısınız.

Bu komut hakkında daha fazla bilgi edinmek için aşağıdaki adresi ziyaret edebilirsiniz:
http://msdn.microsoft.com/en-us/library/ms186865(SQL.90).aspx

"The database must be online to have a database snapshot."

HATA MESAJI:
"The database must be online to have a database snapshot."

AÇIKLAMA:
Bir veritabanının Database Snapshot' ını oluştururken böyle bir hata mesajıyla karşılaşabilirsiniz.

ÇÖZÜM:
Bu hata mesajını, Database Mirroring' e dahil olmayan ve NORECOVERY durumundaki (Restoring...) bir veritabanının Snapshot' ını oluşturmaya çalışırsanız alırsınız.

Eğer Database Snapshot' ını oluşturmaya çalıştığınız veritabanının bir Mirror veritabanı olduğunu düşünüyorsanız, o zaman Database Mirroring' i doğru yapılandırdığınızdan emin olmalısınız.

Eğer Database Snapshot' ını oluşturmaya çalıştığınız veritabanı Database Mirroring' e dahil olmayan normal bir kullanıcı veritabanıysa, o zaman bu veritabanının NORECOVERY durumunda olmadığından emin olun.

"Delivering replicated transactions"

Replication Monitor' de, "Distributor to Subscriber History" isimli sekmede uzun bir süre böyle bir mesaj görebilirsiniz.

Bu mesajı gördüğünüzde de Undistributed Commands sekmesindeki bekleyen komutlar kutusunda birçok (bu birçok milyonları da bulabilir) Transaction' ın Distributor' dan Subscriber' lara henüz gönderilmediğini görebilirsiniz.

Bu gibi durumlara, Publisher tarafında yüklü yeni kayıtlar veya büyük güncellemeler yapıldığında karşılaşılabilir. Sadece sakin ve sabırlı olun. Tüm Transaction' ların zamanla aktarıldığını göreceksiniz.

Ayrıca önlem olarak, varsayılan değeri 72 saat olan ve Distribution Properties' te bulunan Transaction Retention Period' un değerini de uzatabilirsiniz. Bu sayede bazı Subscriber' larınız için Reinitialization işlemi yapmaktan kurtulursunuz. Fakat her şey normale döndükten sonra da bu değeri tekrar varsayılan değerine, yani 72 saate getirmenizi tavsiye ederim.

"The Log Reader Agent failed to construct a replicated command from log sequence number (LSN) {001327a0:00010ec1:000b}. Back up the publication datab

HATA MESAJI:
"The Log Reader Agent failed to construct a replicated command from log sequence number (LSN) {001327a0:00010ec1:000b}. Back up the publication database and contact Customer Support Services. (Source: MSSQLServer, Error number: 18805)"

AÇIKLAMA:
Transactional Replication kurulu bir sistemde, Replication Monitor' de böyle bir hata ile karşılaşabilirsiniz. Bu hata ile birlikte bu hatayı da alabilirsiniz.

ÇÖZÜM:
Bu sorun, SQL Server 2005 SP2 CU9 ve öncesinde; ayrıca SP3 ve öncesinde bir BUG olarak mevcuttur.

Bu sorunu çözmek için, eğer SP2 ile çalışmaya devam etmek istiyorsanız SP2 Cumulative Update 10' u yüklemelisiniz. Eğer SP3 yüklüyse, o zaman da SP3 Cumulative Update 1' i yüklemeniz gerekiyor.

SQL Server 2005 SP2 Cumulative Update 10 için aşağıdaki bağlantıyı kullanabilirsiniz:
http://support.microsoft.com/kb/956854/LN/

SQL Server 2005 SP3 Cumulative Update 1 için aşağıdaki bağlantıyı kullanabilirsiniz:
http://support.microsoft.com/kb/959195/LN/

"An unexpected Text Information Begin (TIB) log record was encountered while processing the TIB for offset 0. Last TIB processed: (textInfoFlags 0

HATA MESAJI:
"An unexpected Text Information Begin (TIB) log record was encountered while processing the TIB for offset 0. Last TIB processed: (textInfoFlags 0xfffffff5, coloffset 3248, newSize 0, oldSize 4294967296). Contact Customer Support Services. (Source: MSSQLServer, Error number: 18834) Get help: http://help/18834"

AÇIKLAMA:
Transactional Replication kurulu bir sistemde, Replication Monitor' de böyle bir hata ile karşılaşabilirsiniz. Bu hata ile birlikte bu hatayı da alabilirsiniz.

ÇÖZÜM:
Bu sorun, SQL Server 2005 SP2 CU9 ve öncesinde; ayrıca SP3 ve öncesinde bir BUG olarak mevcuttur.

Bu sorunu çözmek için, eğer SP2 ile çalışmaya devam etmek istiyorsanız SP2 Cumulative Update 10' u yüklemelisiniz. Eğer SP3 yüklüyse, o zaman da SP3 Cumulative Update 1' i yüklemeniz gerekiyor.

SQL Server 2005 SP2 Cumulative Update 10 için aşağıdaki bağlantıyı kullanabilirsiniz:
http://support.microsoft.com/kb/956854/LN/

SQL Server 2005 SP3 Cumulative Update 1 için aşağıdaki bağlantıyı kullanabilirsiniz:
http://support.microsoft.com/kb/959195/LN/

Bir Database Snapshot' ı Silmek

Normalde, kullanıcıların bağlı olduğu bir veritabanını doğrudan DROP DATABASE komutuyla silemezsiniz; fakat bu veritabanı eğer bir Database Snapshot ise, o zaman doğrudan "DROP DATABASE " gibi bir komutla kaç kullanıcı bağlı olursa olsun bu veritabanını silebilirsiniz. Burada dikkat edilmesi gereken ise, bu komutu çalıştıracak kullanıcının bu Database Snapshot' a o anda bağlantısı olmaması gerektiğidir. Aksi takdirde "Cannot drop database because it is currently in use." hatasını alırsınız.