Bu başlık altında SQL Server Performans tuning, monitoring, optimizasyon ve teşhis için kullanılan DMO (Dynamic Management Objects) olarak adlandırılan DMV (Dynamic Management Views) ve DMF’ler (Dynamic Management Functions) için serinin ilkine bakacağız. SQL Server 2005 öncesinde bunları kendi içinde tablolar ile yapmaktaydı 2005 ve sonrasında bunları DMV ve DMF ile sunmaya başladı. Özellikle sistemde bir sorunla karşılaştığımızda bunu adreslemek istediğimizde ve çözüm için bize hint verebilecek en önemli yapı taşları DMV ve DMF’lerdir. Bu iki yapı doğru okunabilirse ve sorunu adreslemek ve çözmek için bizi iyi bir rehber olacaktır. Dynamic Management View (DMV): Table gibi objectlerdir ve view olarak adlandırılırlar. Select komutu ile bu viewları okuyabiliriz. Dynamic Management Function (DMF): Input parametresi alarak verilen bu parametreye göre sonucu bize döndürecektir. Kullanımı esnasında CROSS APPLY ile function kullanımı sağlanmaktadır. SQL Server’da, Server ve Database kapsamında 2 tür DMV ve DMF vardır. Server kapsamında olanlar, server’a ilişkin bilgileri verir ve bu objelerin […]
Service Principal Name (SPN) nedir? Bu yazımızda Service Principal Name (SPN) hakkında konuşacağız. Active Directory ve SQL Server arasında Kerberos kimlik doğrulaması için kullanılan benzersiz bir tanımlayıcıdır. SQL Server instance’ının hangi Windows hesabı altında çalıştığını belirlemek için kullanılır. Kerberos kimlik doğrulaması, istemci ve sunucunun aynı Windows etki alanında veya güvenilen etki alanlarında olmasını ve SPN’nin Active Directory ile kaydedilmiş olmasını gerektirir. SPN kaydedilmediğinde veya kayıt başarısız olduğunda, Windows güvenlik katmanı hesabı SPN ile ilişkilendiremez ve Kerberos kimlik doğrulaması kullanılmaz. Kerberos nedir dediğimizde ise, Windows 2000’den itibaren Active directory etki alanları için varsayılan kimlik doğrulama protokolüdür. Simetrik şifreleme tekniği kullandığından dolayı NTLM’den daha güvenilir ve daha hızlıdır. Kerberos Authentiction’ın bize faydalarına bakarsak eğer, Client ve server arasında doğrulama yaparak güvenli bir şekilde doğrulama yapmaktadır. Biz buna Mutual Authentication diyoruz. Doğrulama yaparken server ve client arasında ticket alışverişi yapar ve bu alışveriş kriptoludur bu şekilde daha güvenli hale getirir. Bu durumu Secure […]
Bu yazımızda sql server’da arka planda kullanılan, kaynak yönetimini ve sorgularımızı doğrudan ilgilendiren “Cache Plan” hakkında bilgileri ele alacağız. SQL Server’da bir sorgu ilk kez çalıştırıldığında derlenir (compile) ve query için bir plan oluşturulur. Bu plan sayesiyle sorgu hangi adımları izleyeceğini plana göre gerçekleştirir. Ve bu plan SQL Server’da Plan Cache içerisinde depolanır. Görsel -1 Plan cache içerisinde depolanan planlar sayesinde query tekrar geldiğinde yeni bir plan oluşturmasına gerek kalmaz ve aynı planı kullanarak sonucu geri döndürür. Bu sorgu planının ön bellekte kalma süresi sorgunun ne kadar kullanıldığı ile alakalıdır. Daha sık kullanılan sorgular plan cache’te daha fazla kalır. Plan Cache içerisinde tutabileceğim maximum plan sayısı 160.036. SQL Plans, Object Plans, Bound Trees, Extended SPs her biri için bu rakam 40.009’dur. Yoğun ad hoc sorguları SQL Plan bucket sayımızı arttırabilir ve bu durum SOS_CACHESTORE spinlock contention yaşamamıza neden olabilir. Bu durumun üstesinden -T174 Trace flag ekleyerek sayıyı 4 katına çıkarabiliriz. […]
Full-Text Index Fragmentation and Crawl Full-Text Index kullanırken kontrol edilmesi gereken 2 bilgi vardır. Bunlardan biri fragmentation diğeri ise Crawl bilgisi. Fragmentation Bilgisine aşağıdaki scriptinden ulaşılabilir; WITH FragmentationDetails AS ( SELECT table_id, COUNT(*) AS FragmentsCount, CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS IndexSizeMb, CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb FROM sys.fulltext_index_fragments GROUP BY table_id ) SELECT DB_NAME() AS DatabaseName, ftc.fulltext_catalog_id AS CatalogId, ftc.[name] AS CatalogName, fti.change_tracking_state AS ChangeTrackingState, fti.object_id AS BaseObjectId, QUOTENAME(OBJECT_SCHEMA_NAME(fti.object_id)) + '.' + QUOTENAME(OBJECT_NAME(fti.object_id)) AS BaseObjectName, f.IndexSizeMb AS IndexSizeMb, f.FragmentsCount AS FragmentsCount, f.largest_fragment_mb AS IndexLargestFragmentMb, f.IndexSizeMb – f.largest_fragment_mb AS IndexFragmentationSpaceMb, CASE WHEN f.IndexSizeMb = 0 THEN 0 ELSE 100.0 * (f.IndexSizeMb – f.largest_fragment_mb) / f.IndexSizeMb END AS IndexFragmentationPct FROM sys.fulltext_catalogs ftc JOIN sys.fulltext_indexes fti ON fti.fulltext_catalog_id = ftc.fulltext_catalog_id JOIN FragmentationDetails f ON f.table_id = fti.object_id ; Full-text crawl olduğunda veri akışı sağlanmaz ve aramalarda veriyi bulamayabilirsiniz. Aramanın devam etmesi için aşağıdaki script çalıştırılmalı. ALTER FULLTEXT INDEX ON CatalogName SET CHANGE_TRACKING MANUAL; ALTER FULLTEXT INDEX […]
Bu Yazıda Transactional Replcation kullanılan database’in başka bir ortamda StandBy/Read-Only Mod’da Restore ettikten sonra drop edilmek istendiğinde Replikasyondan kaynaklı kaldırılamamasının çözümünü yapacağız. Bu işlemi yaparken profesyonel danışmandan hizmet alınarak kontrollü bir biçimde yapılması gerekmektedir. Aşağıdaki işlemler hata almadan önce sırasıyla yapılan adımları içermektedir. Görsel 1: Database’in drop edilmesi Görsel 2: Database’in script ile drop edilmesi sonrası karşılaşılan hata Database Drop etmek istediğimizde ‘Cannot Drop the Database ‘YourDBName’ Because It Is Being Used for Replication’ hatası ile karşılaşıyoruz. Görsel 3: Drop edilmek istenen database’in sahip olduğu Publication’un silinmesi Görsel 4: Publication’ı kaldırma sonra alınan hata Yukarıda alınan hata StandBy/Read-only mod da çalışan Database üzerinden herhangi bir write işlemi yapılamayacağından kaldırma işleminde yukarıdaki veya başka bir yazma operasyonunda benzer hatalar ile karşılaşılacaktır. Çözüm: StandBy/Read-Only modda olan Database norecovery moda veya recovery moda alınarak açıldıktan sonra kaldırılabilir.
Bu başlık altında SQL Server Transaction Replication’da var olan Publication altından Subscription çıkarma adımlarını göreceğiz. Bu adımı yapılma sebepleri arasında subsription olarak kullanılan sunucunun artık hizmet vermemesinden kaynaklı olarak veyahut başka bir sebepten dolayı bu sunucunun Transaction Replication’dan çıkarma ihtiyacı sonucunda subscription’dan çıkarma adımlarına bakacağız. Bu işlemi yapmadan önce kesinlikle uzmanından profesyonel destek alınız. Sistemin yoğun olduğu saatlerde bu işlemlerşi yapmayınız. 1.Publication (Sistemde kullanılan Publication 3 adet Subscription’a sahip).Aşağıdaki bilgiye Publication olan Server üzerinden görebilirsiniz. kab veri tabanı bizim replication olmasını istediğimiz database. Görsel 1: Publication 2.Distribution (Buradaki joblar sayesinde dataların Snapshot’u alınarak Subscription’a aktarılır.) Görsel 2: Distribution Jobs 3.Subscription (Transactional Replication’da dataların aktarıldığı ortam.) Görsel 3: Replication Sunucusunda Database İşlem olarak kab publication içinde varolan 3 adet subscription’lardan 1 tanesini çıkaracağız. İlk adımımız olan ve kaldırmak istediğimiz subscription üzerine gelip sağ click ve delete diyoruz. Görsel 4: Subscription Delete İkinci adımda önümüze açılan pop-up ekranından […]
Bu yazımızda, SQL Server Transactional Replication ile beslenen databaselerin nasıl oluştuğunu, varolan publications’a, subscription eklemenin adım adım nasıl yapıldığını, karşımıza çıkan hataları ve monitoring etmeyi öğreneceğiz. SQL Server Transactional Replication, ldf içinden logları okuyarak çalıştığı için bu işlemleri yapmadan önce bu konuda çok dikatli olunmalı ve profesyonel destek alınmalıdır. Transactional Replication Kurulumu için önceden kaleme aldığımız Adım Adım Transactional Replication Kurulumu adlı makaleyi okuyabilirsiniz. Bizler bu işlemleri yaparken AlwaysOn mimarisine sahip 2 node’lu ortama, 3. Node eklediğimizde yapılması gereken replikasyon adımlarını inceleyeceğiz. 1.Adım: Publication oluşturma (Bu adım bizde daha önceden var olduğu için bu adımı geçiyoruz.) Görsel 1: SQL Server Transaction Publication bilgisi 2.Adım: Varolan Publication’a, yeni Subscription ekleme seçeneği seçilerek Next diyoruz. Görsel 2: Yeni Subscription Ekleme seçeneği seçilir. 3.Adım: Hangi Database ve hangi Publication’a Subscription eklenecek ise o Database altındaki publication seçilir. Publisher bilgisi AlwaysOn sistemlerinde primary’den yapılması gerekir. Bu yüzden Publisher bilgisini seçerken dikkat edilmelidir. […]
Bu başlıkta, AlwaysOn mimarisinde yönetilen SQL Server’larda Availability Group’un silinmesi veya Secondary Makine’den kaldırılması sonucu ortadan kalkması ve Database’lerin Restoring Mode’a geçmesi durumunun çözümü üzerine konuşacağız. Bu durum genellikle kriz ortamı yaratmakta ve yanlış işlemler sonrası daha büyük felaketlere sebebiyet vermektedir. Aşağıdaki adımları izlerken dikkatli davranmanızı ve uzmanlardan yardım almanızı tavsiye ederiz. Bu işlemi yapmadan daha önce bu bilgilerin ekran görüntüsünü ve bilgisini bir yere lütfen not ediniz. Görsel 1: test_ag remove edeceğimiz Availability Group (AG) Görsel 2: Remove Edilen Availability Group (AG) Görsel 3: test_ag SSMS altında Availability Group (AG)’larda görünmüyor. select name from sys.availability_groups scripti ile AG’nin olup olmadığını kontrol edebilir siniz. Görsel 4: 1.adım : test_ag eski ismi aynı isimde Availability Group (AG) altında yeni AG oluşturma Görsel 5: 2.Adım: test_ag eski ismi aynı isimde Availability Group (AG) altında yeni AG oluşturma Görsel 6: 3.Adım: test_ag eski ismi aynı isimde Availability Group (AG) […]
Error 19405: SQL Server AlwaysOn Replica Eklerken Alınan Hata Bu yazıda SQL Server AlwaysOn sisteminde yer alan Node’lar birini Eklerken karşılaştığımız hatanın çözümüne ilişkin konuşacağız. Hata: Msg 19405, Level 16, State 17, Line 49 Failed to create, join or add replica to availability group ‘blabla_AG’, because node ‘’BLABLATEST1’ is a possible owner for both replica ‘BLABLATEST1\TEST’ and ‘BLABLA\TESTSQL’. If one replica is failover cluster instance, remove the overlapped node from its possible owners and try again. Bu problemle karşılaştığımız ortamda 2 Node Failover Cluster Instance 1 Node ise Always On Mimarisinde çalışmakadır. Toplamda Failover Cluster Manager içeerisinde 3 adet Node bulunmaktadır. Genelde bu hata yukarıda bahsi geçen kullanımlarda daha çok karşılaşılmaktadır. AlwaysOn altında çalışan databaseler ya 1. Makine’de Primary 3. Makine’de Secondary. Ya 2.Makine’de Primary 3. Makine’de Secondary ya da 3.Makine’de Primary diğer 2 Makine’den birinde Secondary olarak çalışmaktadır. 1.Makine’de Primary olan database’in replikasına 3.makineyi eklemek isterken yukarıdaki hata ile […]
Bu yazımızda AlwaysOn Mimarisinde olan 2 sunucudan secondary makine üzerinde olan database’leri yeniden restore etmeden Windows Format sonrası tekrar AlwayOn’a bağlarken yapılması gereken senaryoları adım adım işleyeceğiz. Adım: Sunucu içinde yer alan tüm Cluster Bilgileri Alınır (Ekran Görüntüleri ile Roles ve Nodes bilgileri dâhil). Varsa Witness Share File veya Disk Quarum bilgileri alınır. Buradaki amaç herhangi bir beklenmeyen durumda tüm bilgileri tekrar girip cluster’ı ayağa kaldırmak. Adım: Sunucu içinde kullanmış olduğunuz Disklerin Bilgisini almak. Aşağıdaki komut ile diske ait ihtiyaç olabilecek bilgileri bir csv uzantılı bir dosyaya yazdırabilirsiniz. Bu bilgileri almamızın sebebi, biz sql server yapımızda root and mount disk yapısı kullandığımız için root diske bağlanacak olan mount diskler offline moda çekilecek ve sonrasında tekrar bağlantı yapıldığında doğru diskleri doğru yere bağlamak için bu bilgiler önemlidir. get-disk | select disknumber,uniqueid,FriendlyName,Size | Sort-Object -Property DiskNumber > H:\DiskInf\Disks_All.csv Adım: Sql Server kullanıcı bilgilerini sp_help_revlogin komutu ile bir notepad.txt dosyası […]
