Temporal Table

Temporal table güncel olarak kullandığımız tablolarda yapılan UPDATE ve DELETE işlemlerin daha önceki kayıtlar hakkında bilgisini tutmamızı sağlar. Bunun bir diğer yöntemi cdc dir. Fakat cdc sistemde ciddi bir maliyet oluşturduğu için bu yöntem tercih edilmektedir. CDC hakkında detaylı bilgi için Sql Server Change Data Capture Aktif Etme adlı makaleyi inceleyebilirsiniz. Sql Server 2022 ile birlikte Ledger özelliği ile hash yapıda tutarak daha da güvenlikli hale getirmiştir. Temporal Table özelliği aktif edilecek tabloda Primary Key mutlaka olmalı. Eğer yoksa eklenmeli fakat bu işlem transaction yoğunluğu olan tabloda yapılırken dikkatli yapılmalı!!! Biz işlemlerimizi hali hazırda güncel olarak kullanılan tablo için yapacağımız. Örneği denemek isteyenler için tablonun yapısını aşağıda bulabilirsiniz. USE [ADMINDB] CREATE TABLE [dbo].[TemporalTableTest]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [AcanYerID] [nvarchar](10) NOT NULL, [AcanTelefon] [nvarchar](20) NULL, [Konu] [varchar](150) NOT NULL, [Detay] [nvarchar](1000) NOT NULL, [AlinmaTarihi] [datetime] NOT NULL, [YapilanIslem] [nvarchar](1000) NULL, [IslemTarihi] [datetime] NULL, CONSTRAINT [PK_TemporalTableTest] PRIMARY KEY CLUSTERED ( [ID] […]

Temporal Table

Temporal table güncel olarak kullandığımız tablolarda yapılan UPDATE ve DELETE işlemlerin daha önceki kayıtlar hakkında bilgisini tutmamızı sağlar.
Bunun bir diğer yöntemi cdc dir. Fakat cdc sistemde ciddi bir maliyet oluşturduğu için bu yöntem tercih edilmektedir. CDC hakkında detaylı bilgi için Sql Server Change Data Capture Aktif Etme adlı makaleyi inceleyebilirsiniz.
Sql Server 2022 ile birlikte Ledger özelliği ile hash yapıda tutarak daha da güvenlikli hale getirmiştir.
Temporal Table özelliği aktif edilecek tabloda Primary Key mutlaka olmalı. Eğer yoksa eklenmeli fakat bu işlem transaction yoğunluğu olan tabloda yapılırken dikkatli yapılmalı!!!
Biz işlemlerimizi hali hazırda güncel olarak kullanılan tablo için yapacağımız. Örneği denemek isteyenler için tablonun yapısını aşağıda bulabilirsiniz.

USE [ADMINDB]
CREATE TABLE [dbo].[TemporalTableTest](
	[ID] [bigint] IDENTITY(1,1) NOT NULL,
	[AcanYerID] [nvarchar](10) NOT NULL,
	[AcanTelefon] [nvarchar](20) NULL,
	[Konu] [varchar](150) NOT NULL,
	[Detay] [nvarchar](1000) NOT NULL,
	[AlinmaTarihi] [datetime] NOT NULL,
	[YapilanIslem] [nvarchar](1000) NULL,
	[IslemTarihi] [datetime] NULL,
 CONSTRAINT [PK_TemporalTableTest] PRIMARY KEY CLUSTERED 
(
	[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

—1.Temproral Table Create for Existing table (Adding Two New Column related to Datetime)

use [TemporalTest]
ALTER TABLE [dbo].[TemporalTable]
add BeginDate datetime2 generated always as row start not null 
default SYSUTCDATETIME(),
EndDate datetime2 generated always as row end not null
default cast('9999-12-31 23:59:59.9999999' as datetime2),
period for system_time (BeginDate,EndDate)

BeginDate, EndDate kolonları eklendikten sonra GENERATED ALWAYS AS ROW END NOT NULL şeklinde tabloda oluşacaklar. Bu değerler default olarak SYSUTCDATETIME değerinden gelecek. Burada yaşanabilecek en büyük sıkıntı Türkiye saati GMT+3 olduğu için versioning yaparken transactionlar her zaman 3 saat gerinden yapılmış gibi göreceksiniz. Bu nokta dikkat edilmesi gereken husustur.
–2.Update and Delete Transaction log Information Table

alter table  [dbo].[TemporalTable]
set (system_versioning = on(HISTORY_TABLE =[dbo].[TemporalTable_Log]))
GO

Yukarıda ki komut ile tabloda system_versioning özelliği aktif edilerek. Tabloda yapılacak tüm UPDATE ve DELETE işlemleri History Tablosunda tutulacaktır.

–3.Adding New Row in Temporal Table (Insert Transaction)

Insert Into [TemporalTableTest]
values('Test','05555555555','Temporal Table özelliğini aktif etmek için ','Her Şey daha iyi bir database için',dateadd(day,-1,getdate()),'Test',getdate(),default,default)

–4.Update Transaction existing data in Temporal Table (Update Transaction)

update [TemporalTableTest]
set [AlinmaTarihi] = getdate()
where [YapilanIslem] = 'Test'

SELECT * FROM [dbo].[TemporalTableTest]
SELECT * FROM [dbo].[TemporalTableTest_History]

–5.Delete Transaction updating data in Temporal Table (Delete Transaction)

delete from  [TemporalTableTest] where [YapilanIslem] = 'Test'

SELECT * FROM [dbo].[TemporalTableTest]

SELECT * FROM [dbo].[TemporalTableTest_History]

Aktif ettikten sonra temporal table özelliğini tekrar kapatabiliriz. Bunun için aşağıdaki scriptleri kullanabilirsiniz.

–1.Temproral Table Off

alter table [dbo].[TemporalTableTest] set (system_versioning = off)

–2.Temproral table system_time drop

alter table [dbo].[TemporalTableTest]
drop PERIOD FOR SYSTEM_TIME

–Creating two column drop

alter table [dbo].[TemporalTableTest] drop column [BeginDate]
go
alter table [dbo].[TemporalTableTest] drop column [EndDate]
Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

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ı […]

0 Yorum

Yorum Yaz

Rastgele