Veri yönetiminde karşılaşılan zorluklardan biri, hassas bilgilerin korunmasını sağlarken bu bilgilerin kullanımını sürdürmektir. Dynamic Data Masking (DDM), bu dengenin sağlanmasına yardımcı olarak, veri tabanlarındaki hassas verileri gizleyip, yetkili kullanıcıların yalnızca gerekli bilgileri görmesini mümkün kılar. Dynamic Data Masking’de default, email, ve partial olmak üzere üç adet parametre bulunmaktadır. default: Bu yöntem ile yapacağınız veri maskeleme işlemlerinde kolonun veri tipine göre maskeleme işlemi yapar. Metinsel kolonlarda veri maskelemeyi ‘xxx’ değeri ile yapar. Sayısal kolonlarda veri maskelemeyi tek byte’lık 0 değeri ile yapar. Tarihsel kolonlarda veri maskelemeyi ‘01.01.1700 00:00:00.0000000’ değeri ile yapar. email: E-Mail maskeleme işlemininde bu yöntemi kullanırız. Sadece ilk harfini alarak geri kalanını “XXX@XXXX.com” şeklinde şifreler. Örneğin;FXXX@XXXX.com partial: Veriyi istediğiniz formatta maskeleyebileceğiniz fonksiyondur.Kullanımına Örnek vermek gerekirse; partial(2,A,2) fonksiyonuyla maskelenmiş bir kolonda verilerin baştan iki karakteri ve sondan iki karakterini gösterecek kalan karakterlerini A harfiyle maskeleyecektir. random:Veriyi belirlemiş olduğunuz değerler arasında rastgele değerlerle maskeler. Numaric alanlarda kullanılır. Örnek vermek gerekirse; random(10,20) fonksiyonuyla kolona gelen […]
Modern veri merkezlerinde ve büyük ölçekli bilişim sistemlerinde, sistemlerin esnekliği ve verimliliği üzerine yapılan çalışmalar, partition switch’lerin (bölünme anahtarları) kritik rolünü giderek daha belirgin hale getirmektedir. Bu yazımızda sizlere Partition Switch işleminden bahsedeceğim. Partition Switch öncesi Partition işleminin nasıl yapıldığı hakkında bilgi almak için Duran BÜYÜKÖZTÜRK hocamın SQL Server Table Partition Oluşturmak makalesine göz atabilirsiniz. Öncelikle yapısal olarak birebir eş iki tablo oluşturuyoruz (Alan sayıları ve alanların Data tipleri eşit ve her ikisi de aynı Partition schema üzerinden partiton yapılmış). Resimde görüldüğü üzere içerisinde veri bulunan tablomuz ‘Satislar’, İçerisine switch işlemi ile verileri atacağımız tablomuz ‘Satislar2’. Bu iki tablo yapısal olarak birbirleriyle eş tablolardır ve aynı partition schema üzerine partition yapılmıştır. SELECT p.partition_number,p.partition_id, fg.name AS [filegroup],r.boundary_id, CONVERT(DATE,r.value) AS BoundaryValue, p.rows FROM sys.tables AS t INNER JOIN sys.indexes AS i ON t.object_id = i.object_id INNER JOIN sys.partitions AS p ON i.object_id = p.object_id AND i.index_id = p.index_id INNER JOIN sys.allocation_units a […]
SQL Server’da Columnstore Index Arşivlenmiş veriler, büyük veri ambarları ve analitik sorgular için performansı artıran bir index türüdür. Geleneksel satır tabanlı Index yerine, verileri sütunlar halinde depolar ve sorgu performansını önemli ölçüde artırır. MSSQL Server ‘da ColumnStore İndex ‘in Avantajları, Kullanım alanları , Sürümlere göre farkları , Performansa etkisi ve en önemlisi Data boyutunuzdaki Compress(Sıkıştırma) özelliğini nasıl kullandığını anlatmaya çalışacağım. İlk olarak SQL Server 2012‘de tanıtılan Columnstore Index, sütun bazında depolanan İndex’in oluşturulmasına olanak tanıyan ve Memory kullanan bir yapıdır. Sorgu performansını mükemmel seviyeye taşıyabilecek bir index türüdür. Bir columnstore index, verileri farklı bir index Pagelerde depolar ve verileri büyük ölçüde sıkıştırır. Ayrıca, işleme hızını büyük ölçüde artıran ve CPU kullanımını azaltan yeni bir Batch Mode Processing modu sunar. Yeni depolama türü, sıkıştırılmış veriler ve batch mode processing işleminin birleşimi, SQL Server’ın daha az veri okumasını ve sorgu performansını büyük ölçüde iyileştirmesini sağlar. Peki bu yeni index geleneksel index’den nasıl […]
SQL Server’da tablo oluştururken kolonu yanlış konumlandırdım diyenlerdenseniz doğru yazıyı okuyorsunuz. SQL Server’da bir tablo oluştururken kolonların sırasını yanlış konumlandırabilirsiniz. Ancak, kolonların sırasını değiştirmek oldukça kolaydır ve aşağıdaki örnek olarak yaptığım adımları izleyerek bunu yapabilirsiniz. Test Veritabanımızın altında bulunan “kisiler” tablosunu oluştururken sırasıyla “ad” ve “soyad” kolonlarını oluşturmak isterken önce “soyad” ardından “ad” kolonunu yazdığınızı varsayalım. Tabloyu silip tekrar oluşturmak veya kolon isimlerini değiştirmekte bir yöntemdir ancak burada içerisine çok sayıda veri yazılan bir tablo olduğunu varsayarak başka bir yöntem kullanacağım. Değişiklik yapmak istediğimiz tabloda “design” kısmına giriyoruz. Görüldüğü üzere “soyad” kolonu önce “ad” kolonu sonra yazılmış. Bunların yerini değiştirmek için “ad” veya “soyad” yazan yerlerin hemen sol tarafında bulunan ok işaretinden istediğimiz yere sürükleyip bırakıyoruz. Yapmamız gereken tek işlem bu aslında. Görüldüğü üzere kolonların yerleri değişti. Bu noktada yapılan işlemi kaydetmemiz lazım. Değişiklikleri kaydettiğimizde karşımıza aşağıdaki hata gelmektedir. Hata Mesajı: Değişikliklerin kaydedilmesine izin verilmez. Yaptığınız değişiklik aşağıdaki tablonun […]
Bu makalede, SQL Server Trace Flag ne olduğunu, nasıl kullanıldığını ve bazı yaygın senaryolarda nasıl faydalı olabileceğini inceleyeceğiz. Trace Flag Nedir ? SQL Server’ın davranışını değiştiren ve çeşitli senaryolarda performansı artıran veya hata ayıklama sürecini kolaylaştıran özel ayarlar olarak tanımlanabilir. Kullanım amaçları genel anlamda kriz anında ihtiyaçlara göre Trace Flags’ler eklenip problemi çözmeye yönelik işlemler yapılabilir. SQL Server Trace Flag seçerken dikkatli olmak önemlidir. Yanlış bir Trace flag etkinleştirilmesi, beklenmedik davranış değişikliklerine veya performans sorunlarına neden olabilir. Bu nedenle, her Trace Flag etkilerini ve kullanım senaryolarını bilmek önemlidir. Trace Flag etkinleştirildikten sonra sistem üzerindeki etkilerini izlemek ve değerlendirmek de önemlidir. Trace Flag nasıl aktif edebiliriz. Bağzı Trace Flag’ ler Service Restart edildikten sonra devreye girecektir. Aktif etmek için; SQL Server Configuration Manager/ SQL Server Services/ SQL Server (InstanceName) Instance’a sağ tıklayıp Properties diyoruz ve Startup Parameters kısmına geliyoruz burada 3 tane System tarafından Default olarak gelen Trace Flag’ler bulunmaktadır. […]
“Not Synchronizing / Suspect” SQL Serer AlwaysOn mimarisinde bulunan sunucuların veri tabanlarında bu sorunun meydana gelmesinde birçok neden vardır. Bunlar; Ağ Sorunları: AlwaysOn mimarisinde, ana sunucu ve ikincil sunucular arasında veri senkronizasyonu için gerekli olan ağ bağlantısı sorunları. Disk Sorunları: Veri tabanı dosyalarının tutulduğu disklerde disk doluluğu, disk arızası gibi disk sorunlarının meydana gelebilir. Log Dosyası Sorunları: Veri tabanlarının log dosyalarının bozulması veya dolması durumu. Bekleyen İşlemler: Veri tabanında bekleyen bir işlem (örneğin, büyük bir sorgu veya bir yedekleme işlemi) diğer işlemleri engellemesi durumunda. Veri tabanı Bozulması: Veri tabanı dosyalarında veya yapılarında bozulma meydana gelmesi. Bakım Yetersizliği: Düzenli yedekleme, veri tabanı kurtarma işlemleri vb. gibi veri tabanı yönetimi için gerekli düzenli bakımların yapılmaması. Bu gibi durumlarda, genellikle SQL Server hata günlüklerine bakarak daha spesifik bir sorun tespit edilebilir ve ardından uygun çözüm yolları belirlenebilir. Biz bu makalede disk sorunu ile karşılaşacağımız için disk sorununun tespiti ve çözümü üzerine gideceğiz. Karşılaşabileceğimiz […]
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. […]
Sql server ortamında bir veri tabanını yedekten geri yüklemeye çalıştığımda veri tabanı kullanılmaktadır geri yükleme başarısız hatası almaktaydım bununla alakalı nasıl bir yol izleyebileceğinize değineceğim Yukarıda göstermiş olduğum hatanın 2 farklı çözüm yolunu sizlere göstermek istiyorum. İlk olarak Veri tabanımızın özellikler kısmına giriyoruz. Bu kısımımda Options sekmesine geldiğimizde ‘Restrict Access’ kısmının ‘MULTI_USER’ olduğunu görmekteyiz bu kısmı ‘SINGLE_USER’ olarak değiştirmemiz gerekmektedir. 2. yöntem olarak Activity Monitor üzerinden açık kalan ve veri tabanımızın kullanıma devam ettiği process’i kapatmamız gerekmektedir. İnstance kısmına gelip sağ tık Activity Monitor sekmesine giriyoruz. Açılan ekranda Processes kısmında veri tabanımızla ilgili olan hizmeti bulup sağ tıkladıktan sonra ‘Kill Process’ sekmesine tıklıyoruz. Artık veri tabanımızı kullanan process kalmadığından restore işlemimizi yapabiliriz.
Sql server’da replikasyonda kullanılan bir veri tabanını restore edip daha sonrasında silmek istediğimde karşılaştığım hatayı sizlerle paylaşmak istiyorum. Bu hatanın anlamı Deneme veri tabanı replikasyon tarafından kullanılmaktadır. Böyle bir senaryo ile karşılaştığınızda Aşağıda vermiş olduğum scriptler işinize yarayacaktır. Select * from sys.databases where is_published=1 Burada replikasyon tarafından kullanılan published olarak hizmet veren veri tabanlarının listesini görüyoruz. Bizim silmek istediğimiz ‘DENEME’ veri tabanının repliklasyonda kullanıldığını görebiliyoruz. Peki bunu nasıl kaldırabilirim? exec sp_removedbreplication ‘DENEME’ Yukarıdaki script yardımıyla replikasyonda kullanılan veri tabanımızı Replikasyondan çıkardıktan sonra silme işlemimizi gerçekleştirebiliriz.
Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]
