Kategori arşivi: SQL Server, Oracle

Sql Server 2000, Sql Server 2005, Sql Server 2008, Sql Server 2012, Sql Server Reporting Services, Oracle, SSIS SQL Server Integration Services

Page Index Kayıt Ekleme Çıkarma – Page Split

Üzerinde index bulunan bir tabloya kayıt eklendiğinde Page ve Row konumları nasıl etkilenir? Page Split ne zaman oluşur?

Birçok yerde indexlenmiş tabloya yeni kayıt eklendiğinde veya mevcut kayıt silindiğinde kayıtların adreslerinin fiziksel olarak değişip değişmediği sorusu gelmektedir. Bunu basit bir örnekle açıklayalım. UYE isminde bir tablo oluşturalım. ID alanı üzerinde Clustered Index oluşturalım. İlk kayıt olarak ID=4 olarak “D” ifadesini ekleyelim.

CREATE TABLE UYE(UyeId INT PRIMARY KEY, AdSoyad VARCHAR(2000))

INSERT UYE VALUES(6,REPLICATE('G',1000))

DBCC IND(‘BLOG’, ‘UYE’, -1) komutuyle sayfalarını listelediğimizde 144 nolu bir data page’in oluştuğunu görüyoruz. Bu sayfanın içeriğine DBCC PAGE(BLOG,1,144,1) komutuyla bakalım. Eklenen satırın konumuna bakmak için Page içerisinde “OFFSET TABLE:” bölümüne baktığımızda bu kaydın adresinin 96 olarak görüyoruz.


Okumaya devam et

SP, View, Function, Trigger, System Base Tables (SQL Server Mimarisi – VI)

Bundan önce SQL Server mimarisini anlattığımız yazılardan table ve index datasının içeriğinin nasıl depolandığını biliyoruz. Peki Stored Procedure, View, Function, Trigger benzeri nesneler nerede store ediliyor. Bunlar tabiki MDF içerisinde aynı mantıkta Page’ler içerisinde saklanmaktadır. Bu nesneler System Base Tables olarak tanımlanan sistem tablolarında tutulmaktadır. Bu tablolar mevcut veri tabanlarına ait metadata bilgisini saklar. Bu tablolar kullanıcı erişimi için değil SQL Server Database Engine tarafından kullanılır. Bu tablolar ancak Dedicated Administrator Connection (DAC) bağlantısıyla erişilebilir. Okumaya devam et

Boot Page, DBCC DBINFO (SQL Server Mimarisi – V)

Boot Page Nedir? Birçok kişi SQL Server’da Boot Page bozulma sorununu yaşamıştır. Her veri tabanı kendisi hakkında kritik bilgileri içeren bir Page’a sahiptir. Bu page FileId=1 ve PageId=9 olarak oluşturulur. Bu sayfanın en önemli özelliği sözkonusu veri tabanını başlangıcını temsil ediyor olmasıdır. Bu sayfanın bozulması durumunda hiçbir şekilde o veri tabanı ayağa kaldırılamaz, DBCC CHECKDB gibi yöntemler de fayda sağlamaz. Page (1:9)’da corrupt oluşması durumunda yapılacak tek şey elimizdeki yedekten Restore işlemi yapmaktır.

DBCC PAGE(BLOG, 1, 9, 3) komutu aracılığıyla BLOG isimli veri tabanının başlangıç sayfasını dump etmiş oluruz. Page’in içeriğinde veri tabanının ilk oluşturulduğu versiyonu, şu anki sunucunun versiyonu (dbi_Version ve dbi_CreateVersion), son (Full, Log, Differential) backup alma zamanı, yedeğin alındığı LSN numarası (Log Sequence Numbers), dirty pages LSN numarası, DBCC CHECKDB en son ne zaman başarıyla çalıştığı (dbi_DBCCLastKnownGood) gibi bilgiler bulunmaktadır.

Bu bilgilere aynı zamanda DBCC DBINFO komutuyla da erişebiliriz.

DBCC DBINFO('BLOG') 
--veya
DBCC DBINFO('BLOG') WITH TABLERESULTS

Boot Page’in bozulması durumunda aşağıdaki gibi bir hata mesajı ile karşılaştırız.

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xcdee22fa; actual: 0xcb6ea2fa). It occurred during a read of page (1:9) in database ID 19 at offset 0x00000000013000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\BLOG.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Table, Index, Clustered, NonClustered, Columnstore (SQL Server Mimarisi – IV )

SQL Server veri tabanı mimarisi serisinin dördüncü bölümünde Table ve Index nesnelerinin nasıl oluşturulduğu, MDF içerisinde nasıl konumlandırıldığını detaylandıracağız. Bu amaçla temel olarak aşağıdaki kavramları incelemiş olacağız.

SQL Server Table, Heap, B-Tree (Balanced Search Tree), Index
Clustered Index,
NonClustered Index,
Columnstore Index

Okumaya devam et

Allocation Unit, IN_ROW_DATA, LOB_DATA, ROW_OVERFLOW_DATA, IAM Page (SQL Server Mimarisi – III)

SQL Server veri tabanı mimarisi serisinin üçüncü bölümünde de SQL Server underground dünyasını detaylandırmaya devam ediyoruz. Bu yazıda fiziksel ve mantıksal mimarinin temel bileşenleri olan aşağıdaki kavramları detaylandırıyor olacağız.

Allocation Unit (IAM)
IN_ROW_DATA Allocation Unit
LOB_DATA Allocation Unit
ROW_OVERFLOW_DATA Allocation Unit

Önceki makalelere aşağıdaki linklerden ulaşabilirsiniz;

SQL Server mimarisi – II (Data Page, Extent, GAM, SGAM, IAM)
SQL Server Mimarisi – I (Database Engine, Storage Engine, SQLOS)

SQL Server verileri fiziksel olarak her biri 8KB olan data page’lerde depolanır. Page’ler veri olarak ya doğrudan tablo datasını veya ona referans veren index datasını saklar. SQL Server üzerinde bir table veya index oluşturduğumuzda otomatik olarak bu nesnelerin altında bir partition oluşturulur. Sonraki yazılarda detaylandıracağımız Partition kavramı temel olarak yönetim kolaylığı ve performans açısından verilerin belli alan(-lar) bazında küçük kümelere bölümlendirilmesidir. Bir tablo bir veyda fazla partition’a içerir. Partition lar da Heap veya Clustered Index yapısında Data Row’ları içerir. Heap veya Clustered Index’a ait Page’ler kolonların verip tipine göre bir veya daha fazla Allocation Unit içerisinde yönetilir. Partition’lar kendisine ait page’leri kolonların tipine göre gruplandırır ve bunların her birine Allocation Unit denilir. “Allocation Unit” kavramını disk mimarisinden hatırlayabiliriz. Allocation Unit, disk üzerindeki sektör kümesini temsil eder yani yönetilebilir en küçük disk alanıdır. SQL Server’de de aynı amaç için kullanılmaktadır.

Okumaya devam et

Data Page, Extent, GAM, SGAM, IAM, PFS (SQL Server Mimarisi – II)

SQL Server veritabanı mimarisi ile ilgili önceki yazıda SQL Server’in bağlantı sağlama, sorgu çalıştırma ve kaynak yönetme motorlarından bahsetmiştik. Bu yazıda fiziksel ve mantıksal mimarinin temel bileşenleri olan aşağıdaki kavramları detaylandırıyor olacağız.
Page
Extent
Database File
Database File Group
Data Page, Extent, GAM, SGAM, IAM

Okumaya devam et

Database Engine, Storage Engine, SQLOS (SQL Server Mimarisi – I)

SQL Server bir makalede anlatılamayacak kadar detaylı bir mimariye sahiptir. Bu makalede hem yeni başlayanlar hem de deneyimli olanlar SQL Server mimarisinin genel yapısını aktarıyor olacağım. Makalede mimariyi anlatmakla birlikte birçok eğitim ve yazıda geçen kavramları da (Database Engine, Storage Engine, SQLOS) netleştirmiş olacağız. Microsoft’un kaynaklarında SQL Server mimarisi ile ilgili aşağıdaki diyagram bulunmaktadır.

Bu diyagrama baktığımızda karşımıza SQL Server veritabanı mimarisi ile ilgili 3 temel bileşen (component) çıkar.

1. SQL Server Network Interface (SNI)
2. Database Engine
  2.1. Relational Engine
  2.2. Storage Engine
3. SQL OS
Okumaya devam et

SQL Server Yüksek CPU Sorunu

Veri tabanı yönetim tarafındaki en büyük kabusumuz disk, işlemci ve bellek kaynaklarının yüksek ölçüde kullanılıyor olmasıdır. Bu yazıda SQL Server tarafından CPU kullanımını nasıl takip edeceğimizi ve yöneteceğimizi örneklendiriyor olacağız. Ayrıca CPU ile ilişki konusunda SQL Server yönetimi konusunda kullandığım farklı kaynaklardan edindiğim birkaç script paylaşıyor olacağım. SQL Server üzerindeki CPU kullanımını izlemek için sp_who2 komutu Activity Monitor veya DMV’ler ((Dynamic Management Views)) kullanılabilir. Sunucuda yüksek CPU kullanımına denk geldiğimizde bakacağımız ilk yer Task Manager aracıdır. Burada SQL Server’in yüksek CPU kullandığından emin olmamız gerekiyor. Task Manager içerisinde sqlservr.exe programının karşısında CPU kullanımı gösterilmektedir. Ardından SQL Server tarafına geçip tam olarak SQL Server’in hangi prosesin bu kaynağı kullandığını takip ederiz. Bunun için kullanacağımız Performance Monitor (perfmon) aracını kullanacağız. SQL Server, her bağlantı için tekil bir numara verir. SPID (SQL Server Process ID) olarak bilinen bu numara tam olarak hangi bağlantıya odaklanmamız konusunda yönlendirici olacak. 1 ve 50 aralığındaki SPID’leri SQL Server, kendisi kullanır. Kullanıcı bağlantılarını 50’den sonra olacak şekilde numaralandırır. SQL’deki her bağlantının işletim tarafındaki thread ile ilişkisini KPID (Kernel Process ID) numarası üzerinden sağlar. ID Thread olarak ta bilinen bu numara SQL tarafından bir thread açıldığı zaman Windows tarafından atanır. Windows tarafındaki thread’lari ayırt etmek için kullanılır. spid ve kpid ilişkisi için master.dbo.sysprocesses DMV’ye bakılabilir.


Okumaya devam et

Shrink Esnasında “Backup, file manipulation operations” Hatası

Management Studio üzerinden veya Job aracılığıyla otomatik olarak SHRINK işlemi yapılmak istendiğinde aşağıdaki hata mesajı alınabilir.
Backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed
Bu hata mesajına veri ambarı projesinde her gece shrink Job çalışırken almıştım. Bu mesajın 2 nedeni olabilir;

      O anda veritabanına ait dosyalarda değişiklik ekleme çıkarma yapılıyorsa. Yani mevcut MDF’lerden biri kaldırılıyor veya yeni MDF ekleniyorsa bu hata mesajı alınabilir. Bunu da bilindiği gibi ALTER DATABASE komutu aracılığıyla ADD FILE veya REMOVE FILE tümceleri kullanılarak yapılmaktadır.
      İkinci neden de o esnada sistemde backup alıyor olmasıdır ki ben de bu şekilde tecrübe edindim.

O esnada bu işlemler yapılıyorsa Shrink işlemi başarısız bir şekilde sonlandırılacaktır.

SQL Server VLF (Virtual Log File) Nedir ?

VLF, SQL Server tarafından dahili olarak yönetilen LDF içerisinde bulunan sanal log dosyalarıdır. Fiziksel log dosyaları (LDF dosyaları) veritabanı sistemi tarafından iç transaction yönetimi için birden fazla mantıksal dosyalara bölümlendirilir. Bir sistemde bu dosyaların sayısı artıkça özellikle sistemin yeniden açılma durumlarında o veritabanının toparlanma süresi (recovery time) uzadığı gibi LOG dosyasına ihtiyaç duyuldukça performans sorunu yaşanır. Bu tür çok log dosyalı veritabanlarında SQL servisini restart ettiğimizde o veritabanı uzun süre “Restoring” modunda kalabiliyor. Bu veritabanının kendine gelme süresi bazen 1-2 saati bulabiliyor.
İdeal durumda VLF sayısının 50 veya altı olması beklenir. Bu rakamın üstündeki her dosya performansı olumsuz etkileyecektir. Mevcut veritabanında ne kadar VLF olduğunu anlamak için DBCC LOGINFO komutu kullanılır.
Bu sayıyı düşürmek için sık sık Transaction Log Backup alınabilir.
BACKUP LOG VeriTabaniAdi TO SurucuAdi
Veya DBCC SHRINKFILE komutu aracılığıyla Transaction Log dosyası mümkün olduğunca sıkıştırılır. Transaction Log içerisinde ne kadar boş alan olduğunu DBCC SQLPERF(LOGSPACE) komutuyla öğrenebiliriz.