SELECT CASE WHEN (GROUPING(sob.name)=1) THEN ‘All_Tables’ ELSE ISNULL(sob.name, ‘unknown’) END AS Table_name, SUM(sys.length) AS Byte_Length FROM sysobjects sob, syscolumns sys WHERE sob.xtype=’u’ AND sys.id=sob.id GROUP BY sob.name WITH CUBE
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSELECT K_Table = FK.TABLE_NAME, FK_Column = CU.COLUMN_NAME, PK_Table = PK.TABLE_NAME, PK_Column = PT.COLUMN_NAME, Constraint_Name = C.CONSTRAINT_NAME FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS C INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS FK ON C.CONSTRAINT_NAME = FK.CONSTRAINT_NAME INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS PK ON C.UNIQUE_CONSTRAINT_NAME = PK.CONSTRAINT_NAME INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU ON C.CONSTRAINT_NAME = CU.CONSTRAINT_NAME INNER JOIN ( SELECT i1.TABLE_NAME, i2.COLUMN_NAME FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS i1 INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE i2 ON i1.CONSTRAINT_NAME = i2.CONSTRAINT_NAME WHERE i1.CONSTRAINT_TYPE = ‘PRIMARY KEY’ ) PT ON PT.TABLE_NAME = PK.TABLE_NAME —- optional: ORDER BY 1,2,3,4 WHERE PK.TABLE_NAME=’something’WHERE FK.TABLE_NAME=’something’ WHERE PK.TABLE_NAME IN (‘one_thing’, ‘another’) WHERE FK.TABLE_NAME IN (‘one_thing’, ‘another’)
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimVeritabanındaki Tüm İşlemleri Kill Etmek İçin Cursor
Komut dosyasını çalıştırdığınızda, lütfen onu tüm işlemlerin öldürülmesini istediğiniz veritabanından farklı bir veritabanında çalıştırdığınızdan emin olun.CREATE TABLE #TmpWho (spid INT, ecid INT, status VARCHAR(150), loginame VARCHAR(150), hostname VARCHAR(150), blk INT, dbname VARCHAR(150), cmd VARCHAR(150)) INSERT INTO #TmpWho EXEC sp_who DECLARE @spid INT DECLARE @tString VARCHAR(15) DECLARE @getspid CURSOR SET @getspid = CURSOR FOR SELECT spid FROM #TmpWho WHERE dbname = ‘mydb’OPEN @getspid FETCH NEXT FROM @getspid INTO @spid WHILE @@FETCH_STATUS = 0 BEGIN SET @tString = ‘KILL ‘ + CAST(@spid AS VARCHAR(5)) EXEC(@tString) FETCH NEXT FROM @getspid INTO @spid END CLOSE @getspid DEALLOCATE @getspid DROP TABLE #TmpWho GO
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişim—-Option 1 SELECT DISTINCT so.name FROM syscomments sc INNER JOIN sysobjects so ON sc.id=so.id WHERE sc.TEXT LIKE ‘%tablename%’ —-Option 2 SELECT DISTINCT o.name, o.xtype FROM syscomments c INNER JOIN sysobjects o ON c.id=o.id WHERE c.TEXT LIKE ‘%tablename%’
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSET NOCOUNT ON DECLARE @lcl_name VARCHAR(100) DECLARE cur_name CURSOR FOR SELECT name FROM sysobjects WHERE type = ‘U’ AND crdate <= DATEADD(m,-1,GETDATE()) AND name LIKE ‘b_%’ OPEN cur_name FETCH NEXT FROM cur_name INTO @lcl_name WHILE @@Fetch_status = 0 BEGIN SELECT @lcl_name = ‘sp_depends’ +@lcl_name PRINT @lcl_name — EXEC (@lcl_name) FETCH NEXT FROM cur_name INTO @lcl_name END CLOSE cur_name DEALLOCATE cur_name SET NOCOUNT OFFİşte cursorlarla ilgili olarak hatırlanması gereken noktalardan birkaçı.
- Cursorlar, WHILE döngülerini kullandıkları için döngülerden başka bir şey değildir.
- Cusror’ların aşırı kullanımı, çok fazla kaynak kullanabileceklerinden sorgu performansını olumsuz etkileyebilir.
- Bir seferde bir satır eklemek için imleç yerine küme teorisini, SELECT…INSERT veya INSERT INTO…SELECT gibi işlemleri kullanmak daha iyidir.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSELECT ‘ALTER TABLE [‘+po.name+’] DROP CONSTRAINT [‘ + so.name + ‘]’ FROM sysobjects so INNER JOIN sysconstraints sc ON so.id = sc.constid INNER JOIN syscolumns col ON sc.colid = col.colid AND so.parent_obj = col.id AND col.name LIKE ‘dep[_]%’ INNER JOIN sysobjects po ON so.parent_obj = po.id WHERE so.xtype = ‘D’ ORDER BY po.name, col.name
SELECT ‘ALTER TABLE [‘+table_schema+’].[‘+Table_name+’] DROP COLUMN [‘ + Column_name + ‘]’ FROM INFORMATION_SCHEMA.COLUMNS WHERE column_name LIKE ‘dep[_]%’ ORDER BY Table_name, Column_name
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimBasit Cursor Örneği
Bu, SQL Server Cursor’un en basit örneğidir. Bunu çoğu zaman T-SQL’imizde herhangi bir Cursor kullanımı için kullanıyoruz.DECLARE @AccountID INT DECLARE @getAccountID CURSOR SET @getAccountID = CURSOR FOR SELECT Account_ID FROM Accounts OPEN @getAccountID FETCH NEXT FROM @getAccountID INTO @AccountID WHILE @@FETCH_STATUS = 0 BEGIN PRINT @AccountID FETCH NEXT FROM @getAccountID INTO @AccountID END CLOSE @getAccountID DEALLOCATE @getAccountID
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişim- Desteklenen en yeni sürümü yalnızca SQL Server 2014 olan, ancak 2016 veya daha yeni olmayan bir uygulamayla uğraşıyorsunuz.
- Always On Availability Gruplarını kullanmak istiyorsunuz; Ancak bunu buraya koymakta tereddüt ediyoruz çünkü sonraki sürümlerde önemli ölçüde daha iyi olmaya devam ediyorlar. Bunu, AG’yi düşünmek için bile minimum bir başlangıç noktası olarak düşünürdük (2012’yi unutun) çünkü 2014’ten başlayarak, primary değer düşükken bile secondary değer okunabilir.
- Yedeklemelerinizi şifrelemeniz gerekir ve üçüncü taraf bir yedekleme aracı satın almak istemezsiniz.
- Log shipping bir raporlama aracı olarak kullanıyorsunuz ve zor izin gereksinimleriniz var (çünkü bunu kolaylaştıran yeni sunucu düzeyinde roller eklediler.)
- Kodu değiştirmeden daha hızlı performansa ihtiyacınız var ve teste ayıracak çok zamanınız var. 2014’ün Cardinality Estimator (CE) değişiklikleri farklı yürütme planları için yapıldı, ancak bunlar genel olarak daha iyi değil. Hala yavaşlayacak sorguları bulmak için zaman ayırmanız ve bunları nasıl azaltacağınızı bulmanız gerekiyor.
- Bağımsız bir yazılım satıcısısınız (ISV) çünkü 2016 Service Pack 1 size Standard Edition’da birçok Enterprise özelliği sunuyordu. Bu, uygulamanızın hem Standard’daki küçük müşterilerinizde hem de Enterprise’daki büyük müşterilerinizde çalışan tek bir sürümünü yazabileceğiniz anlamına geliyordu.
- Eğer aşırı iyi bilinen ve iyi bir dökümante edilmiş bir ürün istiyorsanız, SQL Server 2016 sizin için oldukça uygun çünkü SQL Server 2016 ‘ya erişmek ve bu ürünü kullanmayı bilen insanlardan hizmet almak oldukça kolaydır.
- Standart Sürümü kullanıyorsunuz -çünkü 128 GB RAM’i destekliyor (ve sorgu planları gibi bazı dahili şeyler için bunun ötesine bile geçebiliyor).
- Birkaç yıl içinde yeni bir sunucu kurmak istiyorsunuz çünkü bu ürün için genişletilmiş destek bile 2026’da sona eriyor.
- Yeni bir uygulama için uyumluluk ihtiyaçlarınız var ve burada özellikle yeni uygulamalardan bahsediyoruz, ancak 2016, değerli verilerinizi korumak ve izlemek için bir şeyler oluşturmanızı kolaylaştıran Always Encrypted, Dynamic Data Masking, Row Level Security ve temporal tables özelliklerini ekliyor. Hala kolay değil, sadece daha kolay.
- Columnstore index’leri kullanmak istiyorsunuz buna başlayacağımız minimum sürüm diyeceğiz çünkü bunlar nihayet güncellenebilir ve aynı tabloda hem columnstore hem de rowstore index’lerine sahip olabilirler. Bu kılavuzda yıllar içinde columnstore’da nelerin değiştiğine dair harika bir karşılaştırma var.
- Sorgu planı izlemeye ihtiyacınız var ve üçüncü taraf bir aracı karşılayamazsınız çünkü Query Store size oldukça güzel yetenekler sunuyor. İnsanlar bunu istediğim kadar kullanmıyor. Yarın tekrar tam zamanlı bir DBA işi alsaydım, bu (ve PowerShell) muhtemelen alacağım iki beceri olurdu.
- Yama uygulamaktan nefret ediyorsunuz çünkü SQL Server 2016 SP3 temelde yolun sonu. Burada hiçbir şey düzeltilmiyor ve kesinlikle bunun için yeni özellikler çıkmıyor. 2023’ün başlarında bile SQL Server 2016 hala en popüler 2. sürüm.
- Her 60-90 günde bir yama uygulamaya isteklisiniz çünkü yıllar ve yıllar eski olsa da, hala düzenli CU’lar çıkıyor.
- Sıfır RPO hedefiniz ve finansal riskleriniz var – çünkü 2017 AG’lere, taahhütlerin birden fazla kopya tarafından alındığını garanti etmenizi sağlayacak yeni bir minimum commit replika ayarı ekledi
- Gelecekteki yükseltmelerin daha kolay olmasını istiyorsunuz çünkü 2017’den itibaren içinde farklı SQL Server sürümleri bulunan bir Distributed Availability Group’a sahip olabilirsiniz. DAG’lar günümüzde çok sağlam ya da iyi belgelenmiş değil, ancak ileride yükseltme yaptığınızda daha kolay yükseltmeler için bir peşinat olarak bu iyi bir fikir olabilir.
- Yüksek performanslı columnstore sorgularına ihtiyacınız var çünkü toplu mod yürütme planları için pek çok harika şeyimiz var.
- SQL Server’ı Linux üzerinde çalıştırmaya kararlısınız ama cidden, sürüm notlarını gözden geçirin ve düzeltilen hataları okumak için her toplu Güncellemeye tıklayın. Cluster hatalarından bazıları gerçekten kötü sonuçlara neden olabilir.
- SQL Server’da makine öğrenimi ve R yapmaya kararlısınız veri uzmanları için bunu yapmak ön plandadır, ancak bunu yapmak için SQL Server lisansı için çekirdek başına 2.000 ila 7.000 dolar harcadığınızı unutmayın.
- Mümkün olduğunca fazla destek ömrü istiyorsunuz -çünkü 2030’a kadar destekleniyor. Yeni sürümleri seviyorum, ancak çoğumuz bir sürüme mümkün olduğunca uzun süre bağlı kalmak zorundayız ve 2019 size çok fazla yol veriyor.
- Her 30-60 günde bir yama uygulamaya isteklisiniz çünkü bu sürüm olgunlaşmış olsa da, hala bazı büyük hatalar buluyorlar.
- Dokümantasyonla değil, deneyerek öğrenme konusunda rahatsınız çünkü aşağıdaki en yeni özelliklere ulaştıkça, deneme ve öğrenme süreniz artar, çünkü aşağıdaki konularda sektördeki en iyi uygulamalar ÇOK daha azdır.
- Yük ve performans testlerinde iyisiniz çünkü 2019 uyumluluk modunu etkinleştirdiğinizde 2019 birçok harika performans özelliği ekliyor, ancak aynı zamanda mevcut yürütme planlarınızda da büyük değişiklikler yapıyor. Sadece bir sayı seçmek gerekirse, sorgularınızın %99’unun hızlandığını, ancak %1’inin yavaşladığını varsayalım. Bunların hangi %1 olduğunu ve performans düşüşlerini azaltmak için ne yapacağınızı biliyor musunuz? Yavaş sorgularınızı yalnızca 2019’da test edemezsiniz: kabul edilemez derecede yavaşlamadıklarından emin olmak için şu anda hızlı olan sorgularınızı da test etmeniz gerekir.
- Kullanıcı tanımlı işlevlere büyük ölçüde güveniyorsunuz çünkü 2019 bunları önemli ölçüde hızlandırabilir, ancak bu konuda çok fazla test yapmanız ve Microsoft’un birçok iyileştirmeyi geri çektiğini bilmeniz gerekir.
- 2023 itibariyle SQL Server 2019 en büyük kurulum tabanına sahiptir. Uzun vadeli destek için gerçekten iyi bir seçenek.
- Mutlak en uzun desteğe ihtiyacınız var çünkü 2022 – 2033’e kadar desteklenirken, 2019’un desteği 2030’da sona eriyor.
- Her 30 günde bir yama uygulamak istiyorsunuz çünkü bunun gibi yeni sürümlerde yamalar hızlı ve öfkeli bir şekilde geliyor ve özellikle yepyeni özelliklerle oldukça önemli bazı sorunları düzeltiyorlar. Muhtemelen, yepyeni bir sürümü yayınlandığı yıl kullanacaksanız, bunun nedeni yeni özelliklere çok ihtiyacınız olmasıdır. Bunlar en az test edilenlerdir ve en acil düzeltmeleri alırlar bu nedenle sık sık yama yapılması gerekir.
- Bu yamalardaki ciddi hataları sorun etmiyorsunuz çünkü 2022’nin ilk birkaç Kümülatif Güncellemesi oldukça hatalıydı ve şu anda düzeltme CU’ları kaldırmaktır, bu da diğer hatalara karşı korumasız olduğunuz anlamına gelir.
- Microsoft ile iyi bir ilişkiniz var örneğin kendi hesap yöneticiniz olan kurumsal bir müşteriyseniz ve Premier destek biletlerinizin hızla yükseltilmesine yardımcı olabilirler.
- DR planınız Azure Yönetilen Örnekler çünkü bir noktada, 2022 teorik olarak MI’lara yük devretmeyi ve daha da önemlisi, felaket sona erdiğinde geri yük devretmeyi mümkün kılacak. Teorik olarak diyorum çünkü bu özellik hala sınırlı genel önizleme aşamasında ve almak için Microsoft ile iletişime geçmeniz gerekiyor.
- Sorgu performansı izlemeye ihtiyacınız yok çünkü uyumluluk seviyesi 160’taki parametreye duyarlı plan optimizasyonu değişiklikleri temelde izleme araçlarını bozuyor.
Peki doğru cevap nedir?
Yukarıdaki değerlendirmeler ışığında düşündüğümüzde, iş bilgisini de göz önüne aldığımızda, her müşteri ihtiyacının farklılaştığını görmekteyiz. Ancak ortalama bir karara varacak olursak, SQL Server 2019 çoğu insan için oldukça ikna edici bir durum oluşturuyor. Yeni özelliklerin, kararlılığın ve Microsoft support ömrünün iyi bir dengesidir. İnsanların çok çalıştığı ve her yıl her sunucuyu yükseltemediği çoğu çalışma ortamında, bugün 2019’u yüklediğini ve ardından 2022’nin yama sürümünün nasıl gittiğini ve 2022’den sonra bir sonraki sürümü beklediğini görebiliyoruz. er’ın Hangi Sürümünü Kullanmalısınız? SQL Server’ı yüklemeden önce, durun! Gerçekten doğru sürümü kullandığınızdan emin misiniz? Biliyoruz ki mevcut yapıyı korumayı herkes ister ve uygulama hizmet sağlayıcıları sadece eski sürümleri destekleyeceğini söylüyor, ancak şimdi daha yeni bir sürüm için durumunuzu ortaya koyma şansınız var ve bunu yapmanıza yardımcı olacağız. Eğer ihtiyaçlarınız aşağıdaki gibiyse SQL Server 2014’ü seçmelisiniz.- Desteklenen en yeni sürümü yalnızca SQL Server 2014 olan, ancak 2016 veya daha yeni olmayan bir uygulamayla uğraşıyorsunuz.
- Always On Availability Gruplarını kullanmak istiyorsunuz; Ancak bunu buraya koymakta tereddüt ediyoruz çünkü sonraki sürümlerde önemli ölçüde daha iyi olmaya devam ediyorlar. Bunu, AG’yi düşünmek için bile minimum bir başlangıç noktası olarak düşünürdük (2012’yi unutun) çünkü 2014’ten başlayarak, primary değer düşükken bile secondary değer okunabilir.
- Yedeklemelerinizi şifrelemeniz gerekir ve üçüncü taraf bir yedekleme aracı satın almak istemezsiniz.
- Log shipping bir raporlama aracı olarak kullanıyorsunuz ve zor izin gereksinimleriniz var (çünkü bunu kolaylaştıran yeni sunucu düzeyinde roller eklediler.)
- Kodu değiştirmeden daha hızlı performansa ihtiyacınız var ve teste ayıracak çok zamanınız var. 2014’ün Cardinality Estimator (CE) değişiklikleri farklı yürütme planları için yapıldı, ancak bunlar genel olarak daha iyi değil. Hala yavaşlayacak sorguları bulmak için zaman ayırmanız ve bunları nasıl azaltacağınızı bulmanız gerekiyor.
- Bağımsız bir yazılım satıcısısınız (ISV) çünkü 2016 Service Pack 1 size Standard Edition’da birçok Enterprise özelliği sunuyordu. Bu, uygulamanızın hem Standard’daki küçük müşterilerinizde hem de Enterprise’daki büyük müşterilerinizde çalışan tek bir sürümünü yazabileceğiniz anlamına geliyordu.
- Eğer aşırı iyi bilinen ve iyi bir dökümante edilmiş bir ürün istiyorsanız, SQL Server 2016 sizin için oldukça uygun çünkü SQL Server 2016 ‘ya erişmek ve bu ürünü kullanmayı bilen insanlardan hizmet almak oldukça kolaydır.
- Standart Sürümü kullanıyorsunuz -çünkü 128 GB RAM’i destekliyor (ve sorgu planları gibi bazı dahili şeyler için bunun ötesine bile geçebiliyor).
- Birkaç yıl içinde yeni bir sunucu kurmak istiyorsunuz çünkü bu ürün için genişletilmiş destek bile 2026’da sona eriyor.
- Yeni bir uygulama için uyumluluk ihtiyaçlarınız var ve burada özellikle yeni uygulamalardan bahsediyoruz, ancak 2016, değerli verilerinizi korumak ve izlemek için bir şeyler oluşturmanızı kolaylaştıran Always Encrypted, Dynamic Data Masking, Row Level Security ve temporal tables özelliklerini ekliyor. Hala kolay değil, sadece daha kolay.
- Columnstore index’leri kullanmak istiyorsunuz buna başlayacağımız minimum sürüm diyeceğiz çünkü bunlar nihayet güncellenebilir ve aynı tabloda hem columnstore hem de rowstore index’lerine sahip olabilirler. Bu kılavuzda yıllar içinde columnstore’da nelerin değiştiğine dair harika bir karşılaştırma var.
- Sorgu planı izlemeye ihtiyacınız var ve üçüncü taraf bir aracı karşılayamazsınız çünkü Query Store size oldukça güzel yetenekler sunuyor. İnsanlar bunu istediğim kadar kullanmıyor. Yarın tekrar tam zamanlı bir DBA işi alsaydım, bu (ve PowerShell) muhtemelen alacağım iki beceri olurdu.
- Yama uygulamaktan nefret ediyorsunuz çünkü SQL Server 2016 SP3 temelde yolun sonu. Burada hiçbir şey düzeltilmiyor ve kesinlikle bunun için yeni özellikler çıkmıyor. 2023’ün başlarında bile SQL Server 2016 hala en popüler 2. sürüm.
- Her 60-90 günde bir yama uygulamaya isteklisiniz çünkü yıllar ve yıllar eski olsa da, hala düzenli CU’lar çıkıyor.
- Sıfır RPO hedefiniz ve finansal riskleriniz var – çünkü 2017 AG’lere, taahhütlerin birden fazla kopya tarafından alındığını garanti etmenizi sağlayacak yeni bir minimum commit replika ayarı ekledi
- Gelecekteki yükseltmelerin daha kolay olmasını istiyorsunuz çünkü 2017’den itibaren içinde farklı SQL Server sürümleri bulunan bir Distributed Availability Group’a sahip olabilirsiniz. DAG’lar günümüzde çok sağlam ya da iyi belgelenmiş değil, ancak ileride yükseltme yaptığınızda daha kolay yükseltmeler için bir peşinat olarak bu iyi bir fikir olabilir.
- Yüksek performanslı columnstore sorgularına ihtiyacınız var çünkü toplu mod yürütme planları için pek çok harika şeyimiz var.
- SQL Server’ı Linux üzerinde çalıştırmaya kararlısınız ama cidden, sürüm notlarını gözden geçirin ve düzeltilen hataları okumak için her toplu Güncellemeye tıklayın. Cluster hatalarından bazıları gerçekten kötü sonuçlara neden olabilir.
- SQL Server’da makine öğrenimi ve R yapmaya kararlısınız veri uzmanları için bunu yapmak ön plandadır, ancak bunu yapmak için SQL Server lisansı için çekirdek başına 2.000 ila 7.000 dolar harcadığınızı unutmayın.
- Mümkün olduğunca fazla destek ömrü istiyorsunuz -çünkü 2030’a kadar destekleniyor. Yeni sürümleri seviyorum, ancak çoğumuz bir sürüme mümkün olduğunca uzun süre bağlı kalmak zorundayız ve 2019 size çok fazla yol veriyor.
- Her 30-60 günde bir yama uygulamaya isteklisiniz çünkü bu sürüm olgunlaşmış olsa da, hala bazı büyük hatalar buluyorlar.
- Dokümantasyonla değil, deneyerek öğrenme konusunda rahatsınız çünkü aşağıdaki en yeni özelliklere ulaştıkça, deneme ve öğrenme süreniz artar, çünkü aşağıdaki konularda sektördeki en iyi uygulamalar ÇOK daha azdır.
- Yük ve performans testlerinde iyisiniz çünkü 2019 uyumluluk modunu etkinleştirdiğinizde 2019 birçok harika performans özelliği ekliyor, ancak aynı zamanda mevcut yürütme planlarınızda da büyük değişiklikler yapıyor. Sadece bir sayı seçmek gerekirse, sorgularınızın %99’unun hızlandığını, ancak %1’inin yavaşladığını varsayalım. Bunların hangi %1 olduğunu ve performans düşüşlerini azaltmak için ne yapacağınızı biliyor musunuz? Yavaş sorgularınızı yalnızca 2019’da test edemezsiniz: kabul edilemez derecede yavaşlamadıklarından emin olmak için şu anda hızlı olan sorgularınızı da test etmeniz gerekir.
- Kullanıcı tanımlı işlevlere büyük ölçüde güveniyorsunuz çünkü 2019 bunları önemli ölçüde hızlandırabilir, ancak bu konuda çok fazla test yapmanız ve Microsoft’un birçok iyileştirmeyi geri çektiğini bilmeniz gerekir.
- 2023 itibariyle SQL Server 2019 en büyük kurulum tabanına sahiptir. Uzun vadeli destek için gerçekten iyi bir seçenek.
- Mutlak en uzun desteğe ihtiyacınız var çünkü 2022 – 2033’e kadar desteklenirken, 2019’un desteği 2030’da sona eriyor.
- Her 30 günde bir yama uygulamak istiyorsunuz çünkü bunun gibi yeni sürümlerde yamalar hızlı ve öfkeli bir şekilde geliyor ve özellikle yepyeni özelliklerle oldukça önemli bazı sorunları düzeltiyorlar. Muhtemelen, yepyeni bir sürümü yayınlandığı yıl kullanacaksanız, bunun nedeni yeni özelliklere çok ihtiyacınız olmasıdır. Bunlar en az test edilenlerdir ve en acil düzeltmeleri alırlar bu nedenle sık sık yama yapılması gerekir.
- Bu yamalardaki ciddi hataları sorun etmiyorsunuz çünkü 2022’nin ilk birkaç Kümülatif Güncellemesi oldukça hatalıydı ve şu anda düzeltme CU’ları kaldırmaktır, bu da diğer hatalara karşı korumasız olduğunuz anlamına gelir.
- Microsoft ile iyi bir ilişkiniz var örneğin kendi hesap yöneticiniz olan kurumsal bir müşteriyseniz ve Premier destek biletlerinizin hızla yükseltilmesine yardımcı olabilirler.
- DR planınız Azure Yönetilen Örnekler çünkü bir noktada, 2022 teorik olarak MI’lara yük devretmeyi ve daha da önemlisi, felaket sona erdiğinde geri yük devretmeyi mümkün kılacak. Teorik olarak diyorum çünkü bu özellik hala sınırlı genel önizleme aşamasında ve almak için Microsoft ile iletişime geçmeniz gerekiyor.
- Sorgu performansı izlemeye ihtiyacınız yok çünkü uyumluluk seviyesi 160’taki parametreye duyarlı plan optimizasyonu değişiklikleri temelde izleme araçlarını bozuyor.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimCREATE TABLE Employee ( EmployeeID INT, FirstName VARCHAR(50), LastName VARCHAR(50) ); GO INSERT INTO Employee VALUES (1, ‘John’, ‘Doe’); INSERT INTO Employee VALUES (2, ‘Jane’, ‘Doe’); INSERT INTO Employee VALUES (3, ‘Bob’, ‘Smith’); INSERT INTO Employee VALUES (4, ‘Alice’, ‘Jones’); GO CREATE TABLE EmployeeCopy ( EmployeeID INT, FirstName VARCHAR(50), LastName VARCHAR(50) );
Cursor Tabanlı Ekleme
Ardından, Çalışan tablosunda yinelenen ve her satırda bir ekleme işlemi gerçekleştiren bir Cursor oluşturacağız. Aşağıdaki komut dosyası bunun nasıl yapılacağını gösterir: Bu Cursor, Çalışan tablosunda yinelenir ve her satır için EmployeeID, FirstName, and LastName sütunlarını alır. Ardından, Çalışan tablosunun bir kopyası olan EmployeeCopy tablosunda bir ekleme işlemi gerçekleştirir. Bu komut dosyası çalıştırılmadan önce EmployeeCopy tablosunun oluşturulması gerektiğini unutmayın.DECLARE @EmployeeID INT; DECLARE @FirstName VARCHAR(50); DECLARE @LastName VARCHAR(50); DECLARE EmployeeCursor CURSOR FOR SELECT EmployeeID, FirstName, LastName FROM Employee; OPEN EmployeeCursor; FETCH NEXT FROM EmployeeCursor INTO @EmployeeID, @FirstName, @LastName; WHILE @@FETCH_STATUS = 0 BEGIN INSERT INTO EmployeeCopy (EmployeeID, FirstName, LastName) VALUES (@EmployeeID, @FirstName, @LastName); FETCH NEXT FROM EmployeeCursor INTO @EmployeeID, @FirstName, @LastName; END CLOSE EmployeeCursor; DEALLOCATE EmployeeCursor;
Set tabanlı Ekleme
Şimdi, Cursor tabanlı eklemeyi set tabanlı eklemeye dönüştürelim. Aşağıdaki komut dosyası bunun nasıl yapılacağını gösterir:INSERT INTO EmployeeCopy (EmployeeID, FirstName, LastName) SELECT EmployeeID, FirstName, LastName FROM Employee;Bu script, Çalışan tablosundan EmployeeID, FirstName, and LastName sütunlarını alan ve bunları EmployeeCopy tablosuna ekleyen bir seçme ifadesi gerçekleştirir. Bu yaklaşım küme tabanlıdır, yani her seferinde bir satır yinelemek yerine sonuç kümesinin tamamı üzerinde aynı anda çalışır.
Performans karşılaştırması
Son olarak, Cursor tabanlı ekleme ile küme tabanlı eklemenin performansını karşılaştıralım. Her yaklaşımın yürütme süresini ölçmek için aşağıdaki betiği kullanabiliriz:DECLARE @StartTime DATETIME; DECLARE @EndTime DATETIME; DECLARE @Duration INT; SET @StartTime = GETDATE(); — … — Cursor-based insert — … SET @EndTime = GETDATE(); SET @Duration = DATEDIFF(MILLISECOND, @StartTime, @EndTime); PRINT ‘Cursor-based insert duration: ‘ + CAST(@Duration AS VARCHAR(10)) + ‘ms’; SET @StartTime = GETDATE(); — … — Setbased insert — … SET @EndTime = GETDATE(); SET @Duration = DATEDIFF(MILLISECOND, @StartTime, @EndTime); PRINT ‘Set-based insert duration: ‘ + CAST(@Duration AS VARCHAR(10)) + ‘ms’;Bu script, Cursor tabanlı eklemenin ve küme tabanlı eklemenin yürütme süresini ölçer ve sonuçları konsola yazdırır. Yürütme süresini ölçmek için Cursor tabanlı ekleme kodunun açıklamasını kaldırmanız gerektiğini unutmayın. Bu betiği çalıştırdığımızda aşağıdaki çıktıyı alıyoruz:
Cursor-based insert duration: 22ms Set-based insert duration: 0msGördüğünüz gibi, küme tabanlı ekleme işlemi Cursor tabanlı ekleme işleminden çok daha hızlıdır ve Cursor tabanlı ekleme için 18 ms ile karşılaştırıldığında yalnızca 0 ms sürer. Bunun nedeni, küme tabanlı eklemenin sonuç kümesinin tamamında aynı anda çalışması, Cursor tabanlı eklemenin ise sonuç kümesinde her seferinde bir satır yineleme yapmasıdır; bu, yavaş ve kaynak yoğun olabilir.
Çözüm
Bu blog gönderimizde, SQL Server’da bir imlecin küme tabanlı bir ekleme işlemine nasıl dönüştürüleceğini gösterdik. Örnek bir tablo oluşturduk, onu bazı verilerle doldurduk ve ardından veriler arasında yinelenen ve her satırda bir ekleme işlemi gerçekleştiren bir Cursor oluşturduk. Daha sonra imleci küme tabanlı bir ekleme işlemine dönüştürdük ve iki yaklaşımın performansını karşılaştırdık. Küme tabanlı ekleme işleminin Cursor tabanlı ekleme işleminden çok daha hızlı ve verimli olduğunu bulduk ve SQL Server’da küme tabanlı işlemleri kullanmanın faydalarını vurgulamış olduk.Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişimSQL Server’da Bir T-SQL Meydan Okuması: En Çok Kazananları Bulmak
Birkaç ay önce, birçok SQL Server Sorgusunun performansını yeniden yazarak iyileştirmemiz gereken Kapsamlı Veritabanı Performansı Healt Check yaptığımız bir danışmanlık anlaşmasına katılmıştık. Bu blog yazısında, iki tabloyu (Çalışanlar ve Departmanlar) içeren ilgi çekici bir SQL zorluğunu keşfedeceğiz. Amaç, her departmanda en yüksek maaş alan (en çok kazanan) üç çalışanı ve bunlara karşılık gelen departman ayrıntılarını bulmaktır. Bu sorunu çözmek için, her biri karmaşık sorguları çözmeye yönelik benzersiz içgörüler sunan iki farklı T-SQL çözümünü inceleyeceğiz. Durumu Hazırlamak Çalışanlar ve Departmanlar tablolarının yapısını ve ilgili verilerini anlayarak başlayalım. Çalışanlar tablosu, Çalışan Kimliği, Adı, Soyadı, Departman Kimliği ve Maaş sütunlarını içerir. Departmanlar tablosu ise DepartmentID, DepartmentName ve Location sütunlarından oluşur.CREATE TABLE Employees ( EmployeeID INT PRIMARY KEY, FirstName VARCHAR(50), LastName VARCHAR(50), DepartmentID INT, Salary DECIMAL(10, 2) ); CREATE TABLE Departments ( DepartmentID INT PRIMARY KEY, DepartmentName VARCHAR(50), Location VARCHAR(50) ); INSERT INTO Departments VALUES (1, ‘HR’, ‘Londra’), (2, ‘Engineering’, ‘Manchester’), (3, ‘Finance’, ‘Plymouth’); INSERT INTO Employees VALUES (1, ‘Ethan’, ‘Anderson’, 1, 70000), (2, ‘Olivia’, ‘Foster’, 1, 80000), (3, ‘Benjamin’, ‘Clarke’, 1, 75000), (4, ‘Ava’, ‘Mitchell’, 1, 80000), (5, ‘William’, ‘Roberts’, 2, 90000), (6, ‘Sophia’, ‘Edwards’, 2, 85000), (7, ‘James’, ‘Bennett’, 2, 95000), (8, ‘Isabella’, ‘Watson’, 2, 90000), (9, ‘Alexander ‘, ‘Nelson’, 3, 100000), (10, ‘Emily’, ‘Turner’, 3, 110000), (11, ‘Jacob’, ‘Parker’, 3, 105000), (12, ‘Mia’, ‘Carter’, 3, 100000);Duruma Genel Bakış-En Çok Kazananlar Buradaki zorluk, birden fazla çalışanın aynı maaşa sahip olma olasılığını göz önünde bulundurarak, her departmanda en yüksek maaş alan ilk üç çalışanı alan bir T-SQL sorgusu yazmaktır. Bir departmanda aynı en yüksek maaşa sahip üçten fazla çalışan varsa hepsinin sonuca dahil edilmesini sağlamak istiyoruz.
1.Çözüm: Ortak Tablo İfadelerini (CTE) Kullanma
Her bir çalışanın ilgili departman içindeki sıralamasını maaşlarına göre azalan düzende hesaplayan, Çalışan Derecesi adlı bir Ortak Tablo İfadesi (CTE) ile başlıyoruz. PARTITION BY yan tümcesi, çalışanları departmana göre gruplamamıza yardımcı olur ve ORDER BY yan tümcesi, onları azalan düzende maaşlarına göre düzenler. Daha sonra RANK() işlevini kullanarak her departmandan en çok maaş alan ilk üç çalışanı seçiyoruz.;WITH EmployeeRank AS ( SELECT e.EmployeeID, e.FirstName, e.LastName, e.DepartmentID, e.Salary, d.DepartmentName, d.Location, DENSE_RANK() OVER (PARTITION BY e.DepartmentID ORDER BY e.Salary DESC) AS Rank FROM Employees e JOIN Departments d ON e.DepartmentID = d.DepartmentID ) SELECT EmployeeID, FirstName, LastName, DepartmentID, Salary, DepartmentName, Location FROM EmployeeRank WHERE Rank <= 4 ORDER BY DepartmentID, Salary DESC;2. Çözüm: Alt Sorguları Kullanma Bu yaklaşımda, istenen sonuca ulaşmak için alt sorgular kullanırız. Ana sorgu, Çalışanlar ve Departmanlar tabloları arasında, departman bilgileriyle birlikte çalışan ayrıntılarını aldığımız bir kendi kendine birleşmeyi içerir. WHERE yan tümcesindeki alt sorgu, aynı departmanda mevcut çalışandan daha yüksek maaşlı farklı çalışanların sayısını sayar. Bir departmanda aynı maaşa sahip tüm çalışanları dahil ettiğimizden emin olarak sayısı üçten az olan çalışanları seçiyoruz.
SELECT e.EmployeeID, e.FirstName, e.LastName, e.DepartmentID, e.Salary, d.DepartmentName, d.Location FROM Employees e JOIN Departments d ON e.DepartmentID = d.DepartmentID WHERE ( SELECT COUNT(DISTINCT e2.Salary) FROM Employees e2 WHERE e2.DepartmentID = e.DepartmentID AND e2.Salary > e.Salary ) < 2 ORDER BY e.DepartmentID, e.Salary DESC;Çözüm T-SQL kullanarak her departmanda en çok kazananları bulma zorluğunu çözmek, düşünceli bir yaklaşım ve gelişmiş SQL tekniklerinin uygulanmasını gerektirir. İki farklı çözüm aracılığıyla, Ortak Tablo İfadelerinin (CTE’ler) ve alt sorguların bu görevi verimli bir şekilde gerçekleştirmek için nasıl kullanılabileceğini gösterdik. SQL uzmanları olarak, bu tür karmaşık sorguları anlamak ve bunlara hakim olmak, veritabanı işlemlerini optimize etmek ve verilerinizden değerli bilgiler elde etmek için çok önemlidir. Not: SQL becerilerinizi daha da geliştirmek ve karmaşık zorlukların üstesinden gelmede T-SQL’in gücünü keşfetmek için sağlanan çözümleri, farklı senaryolar ve veri kümeleriyle denemekten çekinmeyin. Bu şekilde, pratik yaparak SQL yeteneklerinizi daha da ilerletebilir ve gerçek dünya problemlerine uyarlayabilirsiniz. Karmaşık sorgular, veri tabanı tasarımı ve optimizasyon gibi konuları ele alırken, farklı senaryolar ve veri kümeleri üzerinde çalışarak geniş bir perspektif elde edebilirsiniz. Bu da, gerçek hayatta karşılaşabileceğiniz daha karmaşık sorunları çözme becerinizi geliştirmenize yardımcı olacaktır. Unutmayın, pratik yapmak ve denemek, SQL becerilerinizi ilerletmenin önemli bir parçasıdır.
Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!
İletişime geçerek hemen destek alabilirsiniz.
İletişim