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 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 […]
“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 DMV ve DMF serimizin 2.sine devam edeceğiz. Yazımızda sql server query execution sonuçlarını montior etme ve bunları nasıl anlamlandırabileceğimize bakacağız. Yazı sonunda hazır olarak çoğumuzun kullandığı bu DMV ve DMF’lerin nerede ve ne için kullanıldığını öğrenmiş olacağız. Bu seride Connection, Session ve Request bölümlerini inceleyeceğiz. Task ve Worker bölümleri operating system ile alakalı olduğundan dolayı bir sonraki bölümde onları ele alacağız. SQL Server bir session’ın process’i aşağıdaki gibi gerçekleşmektedir. Görsel – 1 Bu süreci detaylandırmak istersek adım adım aşağıda bunları ele alabiliriz. Sql Server’da connection yapıldıktan sonra unique olarak kendine özel bir session alır. Görsel – 2 session_id: Session’ın Id’si connect_time: Connection’ın gerçekleştirildiği tarih net_transport: SQL Server’a gerçekleştirilen bağlantı türü auth_scheme: Gerçekleştirilen bağlantının tipi client_net_address: Bağlantı gerçekleştiren Session’ın IP bilgisi num_reads: Session’ın yapmış olduğu okuma sayısı num_writes: Yapmış olduğu yazma sayısı last_read: Yapılan son okumanın tarihi last_write: Yapılan son yazmanın tarihi Görsel – 3 ve Sql Server […]
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.
Bu yazımızda “.LDF” dosyası üzerinden tail-log backup alarak database’in son commit olan haline kadar geri dönme işlemi nasıl yapılıyor bu konuyu anlatacağım. Ama ondan önce tail-log backup ne için kullanılır ve nedir onu bir açıklayalım; Bir database’i başka bir yere taşımak istediğimizde aşağıdaki görsel’de olduğu gibi bir tail-log backup alırız ve database restoring state düşer işlem yapılamaz olur. Sonrasında aldığımız tail-log’u yeni ayağa kaldırmak istediğimiz instance üzerinde, önceden restore edilen backup zinciri üzerine işleyerek ayağa kaldırırız. Bu şekilde hem veri bütünlüğü korunur(veri kaybı olmaz) hemde kısa süreli kesinti ile db’yi başka bir instance’de ayağa kaldırmış oluruz. Ama ben bu yazıda size daha farklı bir senaryo üzerinde size tail-log’u anlatacağım. DİPNOT OLARAK; tail-log backup alındığında DB restoring state’e düşer, aynı tail-log restore edildiğinde db restoring state’ten Online state’e geçer. Tail-log backup aslında .LDF dosyasını truncate etmeyen bir log backup türevidir. Basit bir senaryo üzerinde anlatacak olursak; Öncelikle bir adet full […]
SQL Server’da kullanmış olduğumuz bir çok fonksiyon vardır. Bu fonksiyonlardan bir taneside tarih ile alakalı olarak kullanmış olduğumuz “DATE” fonksiyonlarıdır. Bu yazımızda sizlere; DATEDIFF DATEPART VE DATENAME DATEADD DATEDIFF_BIG GETDATE Fonksiyolarını anlatacağım. DATEDIFF(interval, date1, date2) FUNCTIONS DATEDIFF() fonksiyonun temel kullanım amacı girilen iki tarih arasında geçen zaman farkı yıl, ay veya gün olarak “INT” türünden almamızı sağlamaktadır. Bu fonksiyon 3 adet parametreden oluşur. Bulmak istediğiniz zaman farkını hangi zaman diliminden istediğiniz(Year-Month-Day) Başlangıç tarihi Bitiş tarihi DATEDIFF_BIG(datepart,startdate,enddate)FUNCTIONS DATEDIFF_BIG fonksiyonu, verilen iki tarih arasındaki farkı “BIGINT” türünden hesaplamaktadır. DATEDIFF fonksiyonuda verilen iki tarih arasındaki farkı hesaplamaktadır fakat “INT” türünden hesap yapar ve bizim yapacağımız çalışma “INT (max=2,147,483,647)”türünden büyük ise yetersiz kalacaktır. Yukarıdaki sorgumuzda DATEDIFF fonksiyonunun yapabileceği işlem limitinden fazla bir değer aralığı yaptık ve hata aldık. Aynı sorguyu DATEDIFF_BIG ile yaptığımızda ise herhangi bir hata almadık DATEPART&DATENAME(datepart , date) FUNCTIONS DATENAME ve DATEPART fonksiyonları belli bir zaman dilimindeki tarihlerin belirtilen bir bölümünü döndürür. Aralarındaki […]
SQL Server’da data boyutlarını hesaplamak için aşağıdaki yöntemi izleyebilirsiniz. Data boyutlarını hesaplarken özellikle allocate edilmiş data ve kullanılan data boyutları farklı olacaktır. Bunun sebebi ise bir veri tabanında oluşturulan bir tablonan boşaltılması veya index’in kaldırılması gibi bir çok etken vardır. SQL Server’da allocate edilen boyutu kullanılan boyuta düşürmek için shrink yapmak gerekir. Fakat data dosyalarında(mdf,ndf) shrink yapmak, özellikle yoğun transaction olan yerlerde büyük risk içermektedir. –1.Adımda Instance altındaki tüm veri tabanlarının İmage ve Image olmayan dataların boyutlarının bilgisini aşağıdaki tabloya yazılmaktadır. USE [master] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[useddata]( [allocation_type] [varchar](12) NOT NULL, [used_mb] [numeric](36, 2) NULL, [allocated_mb] [numeric](36, 2) NULL ) ON [PRIMARY] GO –2.Adımda oluşturmuş olduğumuz tabloya Instance’daki tüm database’lerin bilgilerinin toplandığı script. –Kullanımda olan database'lerinizde . veya başka bir işaret var ise ? yerine [?] yazmanız gerekmektedir. declare @cmd nvarchar(max) set @cmd =' use [?]; insert into master..useddata select case […]
