SQL Server Agent Job History Retention İçin Best Practices’ler
Kategori: Güvenilirlik
SQL Server Agent Job History Retention Nedir?
Silmeden önce SQL Server’ın Job History kayıtlarının miktarını belirleyecektir. Agent job history, history log’u varsayılan olarak belirli sayıda satıra ulaştığında tüm geçmiş kayıtlarını temizlemek için ayarlanmıştır. Log’lar, sorun giderme için yararlıdır; yetersiz kayıtlara sahip olmak sorunları belirlemeyi zorlaştırır.Sorun nasıl belirlenir ve nasıl düzeltilir?
- SSMS (SQL Server Management Studio) kullanarak SQL instance’ye bağlanın;
- SQL Server Agent’a sağ tıklayın ve properties’ı açın;
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server’da Simple Recovery Model
Kategori: Güvenilirlik SQL Server’daki Simple Recovery modeli nedir? Simple Recovery Modeli, SQL Server’da bulunan temel kurtarma modelidir. Yalnızca son Full veya Differential backup’a kadar, basit kurtarmayı kullanarak belirli bir zamana kadar yedekleme yapamazsınız. Full Recovery modu, düzgün bir şekilde yönetildiğinde, bir veritabanının belirli bir zamanda geri yüklenmesine izin verir. Simple Recovery modelini kullanmalı mıyız? Simple Recovery Modeli, kullanıcının verileri kaybetmeyi göze alamayacağı durumlar için ideal değildir. Ne kadar veri kaybını göze alabileceğinizi düşünün. (SQL yedeklemesini bu şekilde ayarlamak kolaydır, böylece herhangi bir olumsuzluk olmadan en fazla 2 dakika kaybedersiniz.) Buna Kurtarma Noktası Hedefi (RPO) denir.- Arıza durumunda ne kadar kesintiye sahip olabileceğinizi düşünün. Bu, Kurtarma Süresi Hedefidir (RTO).
- Bu terimlerin her ikisi de birlikte Hizmet Düzeyi Sözleşmesini (SLA) oluşturur.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server Remote Dedicated Admin Connection (DAC)
Kategori: Güvenilirlik DAC SQL Server nedir? Bir veritabanı yöneticisinin SQL’e erişmesi için bir tanılama bağlantısıdır. DAC, SQL Server yanıt vermediğinde uzaktan sorun gidermeyi kolaylaştırabilir. SQL’de sorunlar olduğunda, oturum açmak, sorunları gidermek ve kesinti süresini önlemek için DAC kullanılabilir. Sorun nasıl belirlenir? DAC’ye varsayılan olarak yalnızca sunucuda çalışan bir istemciden izin verilir. Ağ bağlantılarının onu uzak bir makineden kullanmasını sağlamak en iyi uygulamadır. Aşağıdaki adımları izleyerek özelliğin etkinleştirilip etkinleştirilmediğini kontrol edebilirsiniz:- SSMS’yi kullanarak, SQL Server Instance’a bağlanın ve ardından Sunucuya sağ tıklayın ve aşağıda gösterildiği gibi FACETS’i seçin.
- View Facets penceresinde Facet’i ” Surface Area Configuration ” olarak seçmeniz ve ardından RemoteDacEnabled’ı kontrol etmeniz gerekir.
DAC’yi nasıl etkinleştiririz? Nasıl düzeltilir?
Yalnızca özelliği ENABLED olarak değiştirerek yukarıdaki arabirimi kullanarak etkinleştirebilirsiniz. Başka bir yol da, aşağıdaki betiği çalıştırarak değişikliği uygulamaktır:
sp_configure ‘gelişmiş seçenekleri göster’, 1 gidip geçersiz kılarak yeniden yapılandırın gidin sp_configure ‘uzak yönetici bağlantıları’, 1 gidip geçersiz kılarak yeniden yapılandırınNotlar:
- DAC kullanarak yalnızca SQL Server sysadmin rolünün üyeleri bağlanabilir ve aynı anda yalnızca bir bağlantı yapılabilir.
- Güvenlik duvarı bağlantı noktalarını açtığınızdan emin olun, bu muhtemelen 1434 numaralı bağlantı noktası olacaktır, ancak bu, kurulumunuza bağlı olarak değişir.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server Sayfa Doğrulaması CHECKSUM
Kategori: Güvenilirlik SQL Server’da Sayfa doğrulama nedir? Sayfa Doğrulama, diskten yazıldığında veya okunduğunda sayfaların tutarlılığını doğrulamak için SQL Server tarafından kullanılan mekanizmayı tanımlayan bir veritabanı seçeneğidir. Bu, veritabanını bozma olasılığını azaltır ve iyi bir uygulama olarak, CHECKSUM olarak ayarlanmalıdır. Sorun nasıl belirlenir? SQL Server 2005’ten bu yana Microsoft, SQL Server altyapısı düzeyinde varsayılan olarak sayfa doğrulaması CHECKSUM uygular. Seçenekler sayfasındaki Veritabanı Özellikleri penceresinde kontrol edebilirsiniz:
Nasıl düzeltilir?
Yukarıdaki arabirimi kullanarak ” Page Verify ” özelliğini CHECKSUM olarak değiştirerek seçebilirsiniz. Ayrıca, sunucudaki tüm veritabanlarına değişiklik komut dosyası oluşturmak için aşağıdaki komut dosyasını çalıştırabilirsiniz. Değişiklik betiğini oluşturmak için aşağıdaki sorguyu çalıştırınız:use master go select ‘ALTER DATABASE [‘ + name + ‘] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT; ‘ Command_to_execute from sys.databases where page_verify_option_desc != ‘checksum’; goKomut dosyasının örnek olarak üreteceği çıktı:
ALTER DATABASE [test] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT; ALTER DATABASE [DBA] SET PAGE_VERIFY CHECKSUM WITH NO_WAIT;
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server Agent İçin Fail-Safe Operatör
Kategori: Güvenilirlik SQL Server’da a Fail-Safe Operatör Nedir? A fail-safe operator, belirlenen operatöre ulaşılamadığında uyarı alan yedek kullanıcıdır. SQL Server Agent, MSDB veritabanındaki sistem tablolarıyla iletişim kuramadığında kullanılacaktır. A fail-safe operator, yalnızca belirli dönemlerde bildirim alacak şekilde planlanmış operatörleriniz varsa ve bildirim bu aralığın dışındaysa, bildirim de alacaktır. Örneğin, pazar günü bildirim alacak operatör ayarlanmamışsa, bildirim otomatik olarak güvenli operatöre gider.Sorun nasıl belirlenir? Nasıl düzeltilir?
Microsoft’un best practices’leri, a fail-safe operator belirlemenizi önerir. Aşağıdaki adımları izleyerek SQL Server Management Studio’yu kullanarak yapabilirsiniz:- Object Explorer’da , güvenli olarak atamak istediğiniz SQL Server Agent işlecini içeren sunucuyu genişletmek için artı işaretini tıklatın.
- SQL Server Agent’a sağ tıklayın ve Properties’ı seçin.
- SQL Server Agent Properties’da , Bir sayfa seçin altında Alert System’ı seçin.
- Fail-safe operatör altında, Enable fail-safe operatör’ü seçin.
- Operator listesinde, a fail-safe yapmak istediğiniz operatörü seçin.
- Operatörün nasıl bilgilendirileceğini belirtmek için aşağıdaki onay kutularından herhangi birini veya tümünü seçin: E-posta, Çağrı Cihazı veya Net gönderimi.
- Bittiğinde, OK’a tıklayın.
Notlar:
1- İlk önce Database Mail’i yapılandırmış olmanız gerekir;
2- Ayrıca yapılandırılmış bir operatörünüz olması gerekir.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimBackup Alırken Full Recovery Model’i Dışında Asla Kullanmayınız
Kategori: Güvenilirlik Bunu neden önemsemelisiniz? Full Recovery Model veya Bulk Logged Recovery Modeli bir veritabanı kullanıyorsanız, SQL Server işlemleriniz bittiğinde log dosyasını boşaltmaz. SQL Server veritabanınız maksimum limit olmadan “otomatik büyümeye” bırakılırsa, sunucunuzdaki disk alanı tükenebilir. Bir Backup Log Olup Olmadığını Nasıl Kontrol Edebiliriz? Database için yakın zamanda bir log backup olup olmadığını görmek için aşağıdaki T-SQL sorgusunu kullanabilirsiniz:select top 10 [backupsets].backup_finish_date, [backupsets].type from msdb.dbo.backupset [backupsets] join sys.databases [databases] on [backupsets].[database_name] = [databases].[name] and datediff ( ss, [databases].[create_date] , [backupsets].[database_creation_date] ) = 0 where [backupsets].recovery_model = ‘FULL’ order by [backupsets].backup_finish_date desc
Sorun nasıl giderilir?
Birkaç yol var:- SQL Server’ın yerleşik Bakım Planlarını kullanarak transaction log backup’ları ayarlayabilir veya SQL Server Agent’taki işleri özelleştirmek için ücretsiz araçları kullanabilirsiniz. Daha ayrıntılı okuma için SQL Server Veritabanlarının Yedeklenmesi ve Geri Yüklenmesi ile ilgili çevrimiçi makalemize bakınız.
- Veritabanlarını SIMPLE kurtarma modeline koyabilirsiniz . Bu model, işlem günlüğü yedeklemeleri gerektirmez, ancak herhangi bir sorun olması durumunda son tam veya diferansiyel yedeklemeden bu yana tüm verileri kaybedersiniz.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server Shrink İçin Best Practices
Kategori: Güvenilirlik
SQL’de bir database Shrink(küçültmek) nedir?
Küçülen veri dosyaları, veri sayfalarını taşıyarak ve onu dosya sistemine geri döndürerek alanı kurtarır.Neden veri dosyalarınızı küçültmemelisiniz?
Düzenli olarak küçülen veritabanları (veri dosyaları, daha spesifik olmak gerekirse) korkunç bir şeydir. Kaynakları tüketir ve ciddi dizin parçalanması oluşturur. Otomatik Shrink’in Disabled Olduğundan Emin OlunBest practicesler onu etkinleştirmenizi önermez, bu nedenle devre dışı olup olmadığını kontrol edin.
- SSMS’yi kullanarak Databasesleri genişletin.
- Databases adına sağ tıklayın ve Properties’ı seçin.
- Options sayfasında, Auto Shrink property False olarak ayarlayın, OK’ a tıklayın.
Ayrıca, aşağıda gösterildiği gibi TSQL kullanarak AUTO_SHRINK veritabanı seçeneğini KAPALI olarak değiştirebilirsiniz (“yourdb” yerine veritabanı adınızı koyduğunuzdan emin olun.
ALTER DATABASE yourdb SET AUTO_SHRINK OFFNot: SQL Server Auto Shrink özelliği, SQL Server instance databaseslarda varsayılan olarak devre dışıdır. Bazen Data Files’ları Shrink Etmeniz Gerekebilir. DBCC SHRINKFILE’ı yalnızca istisnai durumlarda kullanın. Yakında kullanıma sunulmayacak büyük miktarda veri sildiyseniz veya birçok büyük indexler(kullanılmayan indexler) düşürdüyseniz. Bu durumlarda (veya her ikisinde):
- Shirink’i çalıştırabileceğiniz düşük kullanımlı sunucu sürelerini belirleyin.
- Monitor Agent Jobs’ı izleyin ve bir outage window yoksa SQL Server’ın engellemesini izleyin.
- DBCC SHRINKFILE kullanın ve shrink yaptığınız dosya için belirli, hedeflenmiş bir boyut belirleyin.
- Shrink bittiğinde, index parçalanmasını azaltmak için ALTER INDEX REORGANIZE kullanın.
- Son olarak, shrink the log file yapın ve ardından VLF sayısını düşük tutmak için açıkça büyütün.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişim- SSMS’yi açın, tools’lara tıklayın.
- Check for Uptades’i seçin.
- SQL Server Management Studio bileşenlerinin geçerli sürümünü ve mevcut en son sürümü görüntüleyen yeni bir pencere açılacaktır. Burada ayrıca otomatik kontrolü etkinleştirebilir veya devre dışı bırakabilirsiniz.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server Başlangıç Parametreleri
Kategori: Güvenilirlik SQL Server başlangıç parametreleri nelerdir? SQL Server’ı yüklediğinizde, kurulum, nasıl başlatılacağını etkileyen bir dizi varsayılan başlatma seçeneğini Microsoft Windows kayıt defterine yazar. Başlangıç sırasında ihtiyaç duyulan belirli dosya konumlarına alternatif bir yol belirlemek ve sunucu çapında bazı koşullar belirtmek için bu başlangıç parametrelerini kullanabilirsiniz. Ayrıca, SQL Server davranışını etkileyen izleme bayraklarını kullanan başlangıç parametrelerini ayarlayabilirsiniz. Nasıl kontrol edebiliriz? Bu başlatma seçeneklerini SQL Server Yapılandırma Yöneticisini kullanarak bulacaksınız: Sağ bölmede, SQL Server’a (<instance_name>) sağ tıklayın ve ardından Properties’e tıklayın.
Başlangıç Parametreleri sekmesinde varsayılan olarak üç parametre bulunur.
- Master veritabanı veri dosyasının konumu (-d)
- Master veritabanı log dosyası yolunun konumu (-l)
- SQL server error log yolu (-e)
Not: Başlangıç seçeneklerinin yanlış kullanımı, sunucu performansını etkileyebilir ve SQL Server’ın başlamasını engelleyebilir.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimTehlikeli SQL Server Derlemelerine Dikkat Edin
Kategori: Güvenilirlik SQL Server’ın derleme sürümünüzle neden ilgilenmelisiniz? SQL Server’ın belirli derleme sürümlerinde bilinen hatalar ve tehditler vardır. Kümelenmiş dizinlerde veri bozulması ve yüksek güvenlik sorunları yaşayabilirsiniz. Çevrimiçi index yeniden oluşturma, Microsoft SQL Server 2012 ve Microsoft SQL Server 2014’ün belirli yapılarındaki birçok satırı değiştiren eşzamanlı sorgularla birlikte kullanıldığında index bozulmasına veya veri kaybına neden olabilir. Nasıl kontrol edilir? Tehlikeli bir SQL Server yapısı kullanıp kullanmadığınızı kontrol etmek için aşağıdaki betiği kullanabilirsiniz:DECLARE @ProductVersion NVARCHAR(128),@ProductVersionMajor DECIMAL(10,2),@ProductVersionMinor DECIMAL(10,2) SET @ProductVersion = CAST(SERVERPROPERTY(‘ProductVersion’) AS NVARCHAR(128)) SELECT @ProductVersionMajor = SUBSTRING(@ProductVersion, 1,CHARINDEX(‘.’, @ProductVersion) + 1 ), @ProductVersionMinor = PARSENAME(CONVERT(varchar(32), @ProductVersion), 2); SELECT @ProductVersion As YourSQLBuild, CASE WHEN (@ProductVersionMajor = 11 AND @ProductVersionMinor >= 3000 AND @ProductVersionMinor <= 3436) OR (@ProductVersionMajor = 11 AND @ProductVersionMinor = 5058) OR (@ProductVersionMajor = 12 AND @ProductVersionMinor >= 2000 AND @ProductVersionMinor <= 2342) THEN ‘Build with high risk of security’ WHEN (@ProductVersionMajor = 10 AND @ProductVersionMinor >= 5500 AND @ProductVersionMinor <= 5512) OR (@ProductVersionMajor = 10 AND @ProductVersionMinor >=5750 AND @ProductVersionMinor <= 5867) OR (@ProductVersionMajor = 10.5 AND @ProductVersionMinor >= 4000 AND @ProductVersionMinor <= 4017) OR (@ProductVersionMajor = 10.5 AND @ProductVersionMinor >= 4251 AND @ProductVersionMinor <= 4319) OR (@ProductVersionMajor = 11 AND @ProductVersionMinor >= 3000 AND @ProductVersionMinor <= 3129) OR (@ProductVersionMajor = 11 AND @ProductVersionMinor >= 3300 AND @ProductVersionMinor <= 3447) OR (@ProductVersionMajor = 12 AND @ProductVersionMinor >= 2000 AND @ProductVersionMinor <= 2253) OR (@ProductVersionMajor = 12 AND @ProductVersionMinor >= 2300 AND @ProductVersionMinor <= 2370) THEN ‘Build with high risk of corruption’
Nasıl düzeltilir?
- En son hizmet paketini (SP) ve en son toplu güncelleştirmeyi (CU) mümkün olan en kısa sürede yükleyin.
- Bu şimdi yapılamıyorsa, dizin bakım işlerinde (SQL Server Agent) en azından MAXDOP =1 kullanın.
- SQL Server’ınızı güncel tutun.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişim

