Bu makale bir önceki makale yapmış olduğumuz ikinci bir log dosyası oluşturduktan sonra ilk log dosyasında sorun giderilip, tekrardan eski yapımıza geçmek için sonradan oluşturulan ikinci log dosyamızdaki veriler ilk log dosyamızın üzerine yazılıp daha sonra ikinci log dosyamızı silme işlemini ele alacağız.Neden ikinci bir log dosyası oluşturmamız gerektiğini ikinci bir log dosyası oluşturmak konulu makalemde belirtmiştim. Bu yapıyı sağlayacak olan shrink işleminde 3. Kısımda bulunan Empty file by migrating the data to other files in the same filegroup yöntemi olmuş olacak. Şimdi uygulamalı bir şekilde oluşturmuş olduğum ikinci log dosyasını ilk log dosyası üzerine atalım. İkinci log dosyasında shrink işlemi yaparak boş alanları işletim sistemini iade ediyorum. Log dosyasının boşalması için shrink işleminden önce bir log backup alıyorum. Log backup aldıktan sonra veritabanının üzerine sağ tıklayıp Task>Shrink>Files sekmesine geliyorum. Gelen ekranda file type kısmında log seçtikten sonra file name kısmında shrink yapacağımız ikinci log dosyamızı seçiyorum. Shrink action bölümünde Empty file […]
Bu makalede ikinci bir log dosya oluşturma işlemini ele almış olacağım. Karşılaşmış olduğum bir sorun üzerine bu makaleyi yazma gereği duydum. Yazım 2 makaleden oluşmaktadır. Bir gün bir veritabanımızın ldf dosyasının boyutu maksimum sınır olan 2 TB olmuştu böyle bir sorunu çözmek için ikinci bir log dosyası oluşturmuştuk. Neden oluşturduğumuz bu makaleden sonraki makalenin konusu olmuş olacak. Çünkü ikinci bir log dosyası oluşturmak mantıklı değil neden diye soracaksanız bir veritabanında sadece bir log dosyası aktif olabilir. Kısacası ya ldf dosyamız dolmuştur veya ldf dosyamızın olduğu diskte yer olmadığından başka bir disk altında büyütülür. Başka bir disk altında büyütmek tek sunucu üzerinde çalışan databaseler için geçerlidir. AlwaysOn gibi high availability çözümlerinde farklı bir disk altında olması sistemin çalışmamasına sebep olacaktır. Herhangi bir database altında birden fazla log dosyası olduğunda sql server sadece bir log dosyasına yazar demiştik. Bu yazma işlemi için hangi log dosyasının autogrowth değeri açıksa veritabanı altında gelen logları […]
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 […]
Bu makalede Sql Server ’da diskine ulaşılamayan bir veri tabanının files taşıma adımlarından bahsedeceğim. Diyelim ki database files konumlandırmış olduğumuz disklerden bir tanesi offline durumuna geçtiğini gördünüz ve diskin durumu hakkında net bilgi edinememektesiniz. Diskin içerisinde bulunan verileri kurtarmak istiyorsunuz ama disk offline durumda olduğundan dolayı içine erişim sağlayamıyorsunuz bu gibi durumda benim kullanmış olduğum bir yöntemi sizinle paylaşmak istiyorum, Robocopy. Şimdi bir örnek üzerinden adım adım neler yapabileceğimize bakalım. Öncelikle database files konumlandırını tespit ediyoruz; SELECT name as FileLogicalName, physical_name as FileLocation FROM sys.master_files WHERE database_id =DB_ID(N’MuratTest’) Görsel – 1 Database files konumlandırını tespit ettikten sonra offline durumuna getirerek ilgili files konumlarını değiştireceğiz. 1) Öncelikle database offline state çekiyoruz. use master GO ALTER DATABASE [MuratTest] SET OFFLINE WITH ROLLBACK IMMEDIATE 2) Database file taşıma işlemlerini gerçekleştiriyoruz, Command Prompt Rus aas administrator ile çalıştırılır; robocopy D:\Data3\Data D:\Data4\Data /mir /mt:60 /r:2 /w:5 /np /ts /bytes /xd >>D:\Data3\log1.txt Görsel – 2 […]
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 […]
Bir veri tabanını Always On Availability Group’a eklerken karşılaşmış olduğum “Password Required” durumunda yapabileceğiniz bir kaç adımdan bahsedeceğim. Öncelikle bu durumla şifrelenmiş veri tabanını Always On Availability Group’a eklerken karşılaşırsınız. Hangi veri tabanlarında şifreleme olduğunu aşağıda script yardımıyla görebilirsiniz. USE MASTER SELECT * FROM sys.symmetric_keys Şimdi gelelim veri tabanımızı Always On Availability Group’a eklemeye Yukarıda gördüğünüz yere veri tabanını uygulamış olduğunuz şifreyi girmeniz daha sonrasında refresh dediğinizde ilerlemenize izin verecektir. Peki şifremizi unuttuysak neler yapabiliriz 🙂 1- Master key’i drop edebiliriz. USE [DENEMEDB] GO DROP MASTER KEY 2- Master key şifresini değiştirebiliriz. ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD=’YENİ_ŞİFRENİZ’ Her adımı denediniz fakat aşağıdaki gibi bir hata alıyorsanız ne yapmanız gerek? Msg 15329, Level 16, State 2, Line 1 The current master key cannot be decrypted. If this is a database master key, you should attempt to open it in the session before performing this operation. The FORCE option […]
