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

SQL SERVER RIGHT-LEFT PARTITION

SQL Server 5 gün önce

SQL Server’da partitioning, büyük veritabanı tablolarını daha yönetilebilir ve performanslı hale getirmek amacıyla kullanılan bir tekniktir. Bu teknik, tablonun verilerini fiziksel olarak değil, mantıksal olarak parçalara ayırır. Veriler, belirli bir partition function ve partition scheme kullanılarak farklı bölümlere yönlendirilir. Partitioning, özellikle büyük veri kümeleriyle çalışan veri tabanlarında sorgu performansını artırır ve veri yönetimini kolaylaştırır. Partition Function ve Partition Scheme nedir? Partition Function: Verilerin hangi kriterlere göre bölüneceğini belirler. Örneğin, bir tarih aralığına göre verileri ayırmak. Partition Scheme: Verilerin hangi filegroup’larda depolanacağını belirler.   Örnek olarak Range LEFT ve Range RIGHT olmak üzere iki ayrı tabloda partition nasıl yapılır sizlere göstereceğim. İlk olarak Range LEFT olan partition yapısından başlayacağım. Öncelikle Veri tabanıma yeni filegroup ve file ekliyorum Şimdi sıra FUNCTION ve SCHEME oluşturmakta ben tablomu yıllık olarak partition yaptım sizler ihtiyaçlarınız doğrultusunda aylık,günlük vs yapabilirsiniz. LEFT partition dediğimiz olay vermiş olduğunuz tarih aralığına eşit bir veri geldiğinde bu veriyi solundaki partition […]

Veritabanı Recovery Pending Durumu ve Düzeltme Seçenekleri

SQL Server 2 hafta önce

İçindekiler Veritabanı Recovery Pending Durumu Nedir? Veritabanı Neden Recover Pending Duruma Düşer? Recovery Pending Durumu Nasıl Çözülür? Sonuç Kaynaklar Veritabanı Recovery Pending Durumu Nedir? SQL Server’da veritabanları bazı nedenlere bağlı olarak “Recovery Pending” (Kurtarma Bekleme)  moduna geçebilir. Veritabanın düzgün bir şekilde kapatılmaması, eksik veya bozuk log dosyaları, disk depolama sorunları, sistemde yaşanan anormal şekilde çökmeler veya MS SQL Server’daki hatalar bu duruma sebep olabilir. Recovery durumu, aslında veritabanını tekrar kullanılabilir hale getirmek için bir kurtarma işlemi yürüttüğünü ifade eder ve üç aşamadan oluşur; Analysis (Analiz): Transaction log incelemesi yapılması ve işlemlerin tamamlanma (Commit) durumunun kontrol edilmesi, Redo (Yeniden İşleme): Tamamlanmış (Commit) ancak henüz diske yazılamamış olan işlemlerin yeniden işlenmesi, Undo (Geri Alma): Başlamış (Begin) ancak tamamlanmamış (Commit) işlemlerin  geri alınmasıdır.   Veritabanı Neden Recover Pending Duruma Düşer? SQL Server Restart Süreci SQL Server servisi restart edildiğinde üzerinde bulunan tüm veritabanları tutarlılığın sağlanması için otomatik olarak recovery moduna girer ve redo/undo […]

SQL Server DMV ve DMF – 6

SQL Server 2 hafta önce

Bu yazımızda DMV ve DMF Serimizin 6.sına devam edeceğiz. Bir önceki seride Memory’ye ilişkin DMV ve DMF’leri ele almıştık. Bu yazıda Memory konusunda devam edeceğiz. SQL server’da Memory kavramı en önemli kavramlardan biridir. Özellikle tüm transaction işlemlerinin önce Buffer sonra disk üzerinden devam ettiğini düşünürsek buffer’ın oynadığı kritik rolü daha iyi anlayabiliriz. Bu yazıda Memory’nin durumunu ve monitör edilmesine bakacağız. Özellikle Performans sorunlarında memory konusunda sorun yaşandığı durumda nasıl okumak gerektiği önemli rol oynamaktadır. Hangi database’de, hangi tablo’da sorun yaşandığına ilişkin bilgilere bu paylaşım sonrasında görebileceğiz. SQL Server’ın Memory kullanım durumunu incelediğimde; select physical_memory_in_use_kb/1048576.0 AS ‘physical_memory_in_use (GB)’, locked_page_allocations_kb/1048576.0 AS ‘locked_page_allocations (GB)’, virtual_address_space_committed_kb/1048576.0 AS ‘virtual_address_space_committed (GB)’, available_commit_limit_kb/1048576.0 AS ‘available_commit_limit (GB)’, page_fault_count as ‘page_fault_count’ from  sys.dm_os_process_memory; Görsel – 1   Physical_memory_in_use: Kullanımda olan Fiziksel Memory miktarını gösterir. locked_page_allocations: Memory’de lock’lanmış olan Page’lerin miktarını belirtir. virtual_address_space_contained: SQL Server VAS(Virtual Adress Space) için ayrılan miktarı belirtir. available_commit_limit: SQL Server tarafından kullanılabilecek Memory Miktarını gösterir. […]

0 Yorum

Yorum Yaz

Rastgele