Windows Servis Aracılığıyla Alınan DB’nin Tablosunu Partition Yapma

Bu makalede gerçek sistemde başka bir kurumdan servisle alınan bir veritabanında partition yapılması uygun görülen bir tablonun belirtilen kolununun partition yapılması amaçlanmaktadır.  Şimdi işlemlerimizi uygulamalı bir şekilde gerçekleştirelim. Aşağıdaki resimde görüldüğü gibi veritabanımızda herhangi bir filegroup yapısının olmadığı bunun için partition yapacağımız tablo için database üzerinde filegroupları oluşturuyorum data file ile birlikte. Not olarak şunu geçmek istiyorum partition yapılacak kolunun not null olma şartı gerekmektedir. Yoksa tablomuzu partition oluşturacağımız zaman hata vermektedir. Gerçek sistemde yapmadan önce test veritabanında yapıyorum. Şimdi yapacağımız adımlar canlı sistemdeki veritabanına servis aracılığıyla veriler gelmekte bu veriler sonradan update edilmediği için bu yöntem yapılır. Adım olarak canlı veritabanımızda partition yapılacak kolundaki tarihleri gözlemleyerek filegroup’lar ve data file’lar ekliyorum. Tarih kolununu gözlemlediğimde 2021 yılı öncesi veriler ve ondan sonra 21-22,22-23 bu şekilde mantık çerçevesinde olması için ilk filegroup ismini FG2020 yapıyorum bu şekilde 7 tane filegroup ekleme işlemlerine geçiyorum. ALTER DATABASE [PartSamp] ADD FILEGROUP [FG2020] go ALTER […]

Windows Servis Aracılığıyla Alınan DB’nin Tablosunu Partition Yapma

Bu makalede gerçek sistemde başka bir kurumdan servisle alınan bir veritabanında partition yapılması uygun görülen bir tablonun belirtilen kolununun partition yapılması amaçlanmaktadır. 

Şimdi işlemlerimizi uygulamalı bir şekilde gerçekleştirelim. Aşağıdaki resimde görüldüğü gibi veritabanımızda herhangi bir filegroup yapısının olmadığı bunun için partition yapacağımız tablo için database üzerinde filegroupları oluşturuyorum data file ile birlikte.

Not olarak şunu geçmek istiyorum partition yapılacak kolunun not null olma şartı gerekmektedir. Yoksa tablomuzu partition oluşturacağımız zaman hata vermektedir.

Gerçek sistemde yapmadan önce test veritabanında yapıyorum.

Şimdi yapacağımız adımlar canlı sistemdeki veritabanına servis aracılığıyla veriler gelmekte bu veriler sonradan update edilmediği için bu yöntem yapılır.

  1. Adım olarak canlı veritabanımızda partition yapılacak kolundaki tarihleri gözlemleyerek filegroup’lar ve data file’lar ekliyorum. Tarih kolununu gözlemlediğimde 2021 yılı öncesi veriler ve ondan sonra 21-22,22-23 bu şekilde mantık çerçevesinde olması için ilk filegroup ismini FG2020 yapıyorum bu şekilde 7 tane filegroup ekleme işlemlerine geçiyorum.
ALTER DATABASE [PartSamp] ADD FILEGROUP [FG2020]
go
ALTER DATABASE [PartSamp] ADD FILE ( NAME = N'FG2020', FILENAME = N'H:\PartSamp\PartSamp_2020.ndf' , SIZE = 8192KB , FILEGROWTH = 65536KB ) TO FILEGROUP [FG2020]
go

 

       2. Adım olarak canlı sistemdeki veritabanımıza bakarak partition oluşturacağımız koluna göre bir partition function ve scheme yapısını oluşturuyoruz. Tabi bu function ve scheme isimlerini  PartSamp veritabanında yapıyoruz.

USE [PartSamp]
GO
CREATE PARTITION FUNCTION [pf_Tarih2](datetime) AS RANGE RIGHT FOR VALUES (N'2021-01-01T00:00:00.000', N'2022-01-01T00:00:00.000', N'2023-01-01T00:00:00.000', N'2024-01-01T00:00:00.000', N'2025-01-01T00:00:00.000', N'2026-01-01T00:00:00.000')
GO

NOT: Function oluştururken right ifadesi bize aşağıdaki scheme yapısında ilk filegroup’un null değerde olacağı daha sonra herhangi bir FG2019 filegroup eklersem FG2019 FG2020’den önce değil sonraki herhangi bir yere konur buda partition yapısının bozulmasına sebep olur bu yüzden partition genellikle bizim artan olduğu için LEFT ifadesinin kullanılmaması gerekmektedir. Ayrıca RIGHT ifadesi 2021-2022 aralığındaki tarihlerden 2021 yılı başlangıç değeri dahil 2022 yılı başlangıç değerinin dahil olmayacağını gösterir.(2021<=tarihlerimiz<2022) Ayrıca left ifadesiyle oluşturursak partition’ı son kısma null değeri koyar buda partition için yeni bir filegroup ve scheme ekleyeceğimiz zaman partition yapısının bozulmasına sebep olur.

CREATE PARTITION SCHEME [ps_Tarih2] AS PARTITION [pf_Tarih2] TO ([FG2020], [FG2021], [FG2022], [FG2023], [FG2024], [FG2025], [FG2026])
GO

3. Adım olarak canlı sistemdeki partition yapılacak tablonun create script’ini alınıp test ortamında partition yapıda olacak şekilde yapılır. Bu tablo oluşturulurken partition scheme yapısına göre oluşturulması gerekir.

Tablonun üzerine sağ tıklayıp aşağıdaki resimdeki adımlardan script’ini alabiliriz.

 

Canlı sistem olduğu için tablomuzu veya isimleri göstermemeye çalışıyorum.

Test ortamımıza  bu tablonun create script’ini kopyaladıktan sonra  tablonun altında bulunan indexs yapısının içerisine bizim partition yapılacak kolununda tanımlanması gerekmektedir. Aşağıdaki resim’dede tablomuzun sadece alt bölümü paylaşılmıştır.

 

NOT:  Bizim partition yapacağımız kolun canlı tablomuzda null değerine sahipti. Create script’ini aldıktan sonra yeni oluşturacağımız partition’lı yapıda partition olabilmesi için [TRHZMNILK] kolunun NOT NULL olması gerekmektedir. Yoksa tablo yapımız oluşmaz hata vermektedir. Aşağıdaki resim canlı sistemdeki kolun değeri null değeri yeni oluşturacağımız tabloda not null yapılması gerekmektedir. Aşağıdaki resim canlı sistemdeki kolun resmi.

4. Adım şimdi oluşturduğumuz bu tablonun partition yapısına geçip geçmediğini kontrol edelim. 

 

Create script’ini alıp  test ortamında  partition scheme’ya göre oluşturmuş olduğum tablonun partition’lı halini yukarıda görülmektedir. Sorgulama script’ini önceki partition makalelerimde görebilirsiniz.

5. Adım olarak gerçek veritabanındaki tabloda bulunan dataları  oluşturmuş olduğum test database’indeki tabloya atıyorum. Tüm verilerimi aktardıktan sonra  canlı veritabanında bulunan tablo altındaki tüm indeksleri partition scheme yapımıza uygun bir şekilde oluşturacağım. Şuan başlangıçta insert işlemimi yapıyorum indexs’leri sonra oluşturacağım amaç verileri hızlı atmak. Bunları  test ortamında süresini bulup gerçek sistemdeki  olabilecek senaryoları tahmin etmek amacımız.

İnsert komutuyla verilerimi belirli yıldan öncekileri atıyorum sırasıyla bu işlemi günümüz verilerine kadar yapmayı planlıyorum.

USE PartSamp
insert [dbo].[TEST_ORTAMINDA_OLUSTURULMUS_TABLO]
select*from [CANLI_VERITABANI_ADI].[dbo].[CANLI_SİSTEMDE_VERİLERİN_OLDUĞU_TABLO] with(nolock)
where [TRHZMNILK]<N'2021-01-01T00:00:00.000'

Verilerimizin partition yapımızda ilgili filegroup’a atılmış olduğunu görmüş oluyoruz.

Verilerin doğru bir şekilde atıldığını görmüş oluyoruz. Diğer yılların verilerinide aşağıdaki komuttaki tarih aralıklarını güncelleyerek değerleri atmış oldum.

insert [dbo].[TEST_ORTAMINDA_OLUSTURULMUS_TABLO]
select*from [CANLI_VERITABANI_ADI].[dbo].[CANLI_SİSTEMDE_VERİLERİN_OLDUĞU_TABLO]  with(nolock)
where N'2024-01-01T00:00:00.000'<=[TRHZMNILK] and [TRHZMNILK]<N'2025-01-01T00:00:00.000'

Bu işlemlerden sonra partition tabloma baktığımda verilerim atıldığını görmüş oluyorum.

Resimde  görüldüğü gibi 2021 ve 2022 yılları arasındaki verilerin gelmediği görülmüştür verileri insert ederken şu hata mesajıyla karşılaşmış oldum.

Violation of PRIMARY KEY constraint ‘PK_TABLO_ADI’. Cannot insert duplicate key in object ‘dbo.TABLO_ADI. The duplicate key value is (166437335, T, 211202770743162, Dec  2 2021  6:50PM).

Bu hatanın sebebi canlı veritabanımda belirtilen id değerinden 2 tane farklı data olması hata vermesine ve verileri atamamamıza sebep oldu. Canlı sistem olduğu için bu yapıya kaldığım yerden devam ettim.

Gerçekten test ortamındaki verileri 1 saate yakın bir sürede attım şimdi verilerimi attıktan sonra gerçek veritabanı altında bulunan tablodaki indexs yapılarının create script’ini alıp test ortamında oluşturuyorum.

Burada dikkat edilmesi gereken ps_Tarih2 şemamızın yazılması gerekmekte ve create script’ini aldığımız tüm indexs’lere TRHZMNILK kolununun eklenmesi gerekmektedir. aşağıda yeni tabloda oluşturulan tüm indexslerin partition scheme yapısına göre dizayn edildiğini görebilirsiniz.

Bu indexsleri  test veritabanında(PartSamp) oluşturduktan sonra  tahmini oluşturma sürelerini görebiliyoruz.

Sonuç olarak yukarıda test işlemlerinde canlı sistemdeki tabloyu başka bir tabloda partition şekilde oluşturduk. Canlı veritabanı altında yukarıdaki işlemleri yapmak istersek bu işlemleri  farklı tablo ismiyle yapmamız gerekli ve son olarak tablo isimlerini rename yaparak eski tabloyu old, yeni oluşturulan tabloyu eski canlı sistemdeki tablo adı olarak değiştirilir.

Bu değişimin sağlıklı olması için bu veritabanına bilgilerin çekildiği servisin kapatılması gerekmektedir.

sp_rename 'canlı_tablo', 'canlı_tablo_eski'

sp_rename 'test_olusturulan_canlı_tablo', 'canlı_tablo'

Yukarıdaki  komutlarla  tablo değiştirildikten sonra servisin açılıp veritabanının aktif edilmesi gerekmektedir. Bu makalede  Windows servis aracılığıyla başka bir ortamdan alınan DB’nin belirlenen tablosuna partition yapmadan önce test ortamında yapmaya çalıştık. Partitionla ilgili daha detaylı bilgiler almak için yunusyucel.com‘u ziyaret edebilirsiniz. Partition – yunusyucel.com

Benzer Yazılar

Failover Cluster Yapısına Quorum Disk Witness Ekleme

SQL Server 1 hafta önce

Bu makalede mevcut Failover Cluster yapısı kurulu olan bir sistemde Quorum Disk Witness ekleme işlemini ele alacağız. Quorum disk kurulumuna geçmeden önce Quorum yapısını ne olduğundan bahsedeyim. Mevcut clusterımızın ayakta kalması için cluster database dosyalarının tutulduğu kısımdır. Bu yapının çalışabilmesi için cluster yapımızda bulunan toplam sunucuların yarısından bir fazla ile sunucu oy hakkına sahip olur ve lider olarak ayağa kalkması sağlanır. Bu yapımız olmasa da olur aslında bir sıkıntı yaşamayız. Sorun şurada karşımıza çıkar iki sunucu aynı anda down oldu ve iki sunucu aynı milisaniye zamanında ayağa kalkmaya çalışırsa mevcut sistemimizin çalışmamasına sebep olur. Bu riskin önüne geçmek için Quorum yapısı oluşturulur. Bu yapılandırmayı yapmasak ta mevcut bir sunucu down olduğunda diğer sunucu up olmaktadır. Genellikle çift yapılı node durumların oluşturulur. İki farklı quorum modeli bulunmaktadır. Bunlar Disk Witness yapısı diğeri ise File Shared Witness yapısıdır. Herhangi bir failover cluster yapısı oluşturduğumuzda cluster’daki sunucularımın göreceği ortak bir iSCSI disk yapılandırılması […]

SQL Server DMV ve DMF – 4

SQL Server 2 hafta önce

Bu yazımızda DMV ve DMF serisinin 3.’süne bakıyor olacağız. Konuya İlişkin daha detaylı bilgiye sahip olmak isterseniz ya da önceki serileri okumak isterseniz. SQL Server DMV ve DMF – I ve SQL Server DMV – II makalelerine göz gezdirilebilirsiniz. Bu yazımızda SQL Server üzerinde yoğun olarak kullandığımız ve SQL Operating system ile ilişkili bilgilere erişmek istediğimizde ihtiyacımız olan DMV ve DMF’lere göz gezdireceğiz. Bildiğiniz gibi DMV ve DMF’ler problem teşhisinde kullanıldığı gibi monitoring etmek içinde çokça kullanılmaktadır. Özellikle Operating system ile ilgili kullanmak istediğimizd sys.dm_os ile başlayanları kullanabiliriz. Peki biz hangi DMV’leri ne için ve nasıl okuyoruz? SQL Server’ın üzerinde koştuğu Windows’un bilgilerine ulaşmak için; SELECT * FROM sys.dm_os_windows_info; Görsel – 1   Windows_sku: Stock Keeping Unit Stock Keeping Unit değeri Windows_release sonucunun hexadecimal çıktısıdır. Görsel – 2 48 = 0x30 olduğunu biliyoruz. Bu değeri hesaplamak için Hexadecimal değeri Binary değere convert ederek elde edebilirsiniz.   SQL Server ve üzerinde […]

SQL Server DMV ve DMF – 3

SQL Server 2 hafta önce

DMV ve DMF serimizin 3. Serisinde sql server executionları arka planda çalışması sonucunda dataları performans anlamında nelere bakabileceğimizi ve bu parametreleri nasıl anlamlandırmamız gerektiğine bakacağız. Özellikle IO ve Memory dar boğazı yaşadığımız zamanlarda arka planda koşan sorgular büyük önem arz etmektedir. Bir önceki makalede kullandığımız DMV ve DMF’lerin detaylandırılmış ve bize hangi sonuçlarını verdiğini bu yazıda öğrenmiş olacağız. Özellikle Expensive Query olarak adlandırdığımız maliyetli sorguları kimi zaman sorun anında bulmak büyük sorunlar teşkil edebilmektedir. Sorunu doğru adreslediğimiz zaman çözüm noktasında ilerleme kaydetmiş oluyoruz. Şimdi hep birlikte performs dar boğazı yaratan sorguları nasıl bulabilirim konusunda bakalım. select top 50 coalesce (db_name(st.dbid), db_name(convert (int, pa.value)), ‘Empty’) as DBName, qs.last_execution_time as LastExecutionTime, SUBSTRING(st.text, (qs.statement_start_offset/2)+1, ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END – qs.statement_start_offset)/2) + 1) AS StatementText, st.text as ProcedureTextOrBatchText, qs.execution_count as ExecutionCount, (qs.total_worker_time/1000) as CPUTimeTotal, ((qs.total_worker_time/1000)/qs.execution_count) as CPUTimeAvg, (qs.total_elapsed_time/1000) as DurationTimeTotal, ((qs.total_elapsed_time/1000)/qs.execution_count) as DurationTimeAvg, qs.total_physical_reads as PhysicalReadsTotal, (qs.total_physical_reads/qs.execution_count) as PhysicalReadsAvg, […]

0 Yorum

Yorum Yaz

Rastgele