SQL Server “TempDB” Nedir?

SQL Server’da bulunan system database’leri, Tüm sisteme, veri tabanları ait kritik bilgileri tutar. TempDB bu System database’lerinden biridir. Öncelikle TempDB nedir? ve ne işe yarar? TempDB sistem üzerinde geçici objeleri saklayan veritabanıdır. Bu yüzdende diğer sistem veri tabanları gibi sistemin hayatına devam edebilmesi için büyük öneme sahiptir. Bu sistem veri tabanı genel olarak içerisinde şunları barındırır: Geçici tablolar(Temp Tables) ve buna ait veriler. Stored Procedur’ler Tablo Değişkenleri Online index işlemleri Trigger’lar İstatistik Güncellemeleri(Statistics Updates) Cursor’lar DBCC CheckDb Komutu Operasyonları Join İşlemleri SQL Server servisi yeniden başlatıldığında TempDB tekrar drop edilip yeniden oluşturulur. Bu yüzden verileri düzenli olarak tempDB’de saklamak pekte güvenilir bir yöntem tercihi değildir. TempDB hakkında biraz daha detaylı bilgi edinecek olursak: Yedeği alınamaz dolayısıyla yedekten geri dönülemez Recovery modelini değiştiremeyiz default olarak simple modeldedir FileGroup sayısını arttırmamız mümkün değildir Read Only mode’a alınabilme özelliğine sahip değildir TempDB içerisinde normal veritabanında oluşturduğumuz gibi bir allocation süreci işler bu süreçte […]

SQL Server “TempDB” Nedir?

SQL Server’da bulunan system database’leri, Tüm sisteme, veri tabanları ait kritik bilgileri tutar. TempDB bu System database’lerinden biridir. Öncelikle TempDB nedir? ve ne işe yarar?

TempDB sistem üzerinde geçici objeleri saklayan veritabanıdır. Bu yüzdende diğer sistem veri tabanları gibi sistemin hayatına devam edebilmesi için büyük öneme sahiptir. Bu sistem veri tabanı genel olarak içerisinde şunları barındırır:

  • Geçici tablolar(Temp Tables) ve buna ait veriler.
  • Stored Procedur’ler
  • Tablo Değişkenleri
  • Online index işlemleri
  • Trigger’lar
  • İstatistik Güncellemeleri(Statistics Updates)
  • Cursor’lar
  • DBCC CheckDb Komutu Operasyonları
  • Join İşlemleri

SQL Server servisi yeniden başlatıldığında TempDB tekrar drop edilip yeniden oluşturulur. Bu yüzden verileri düzenli olarak tempDB’de saklamak pekte güvenilir bir yöntem tercihi değildir. TempDB hakkında biraz daha detaylı bilgi edinecek olursak:

  1. Yedeği alınamaz dolayısıyla yedekten geri dönülemez
  2. Recovery modelini değiştiremeyiz default olarak simple modeldedir
  3. FileGroup sayısını arttırmamız mümkün değildir
  4. Read Only mode’a alınabilme özelliğine sahip değildir

TempDB içerisinde normal veritabanında oluşturduğumuz gibi bir allocation süreci işler bu süreçte üç adet page söz konusudur. Bunlar PFS(Page Free Space), GAM(Global Allocation Map), SGAM(Shared Global Allocation Map) Her bir tempDB data file için birer adet PFS ve SGAM page mevcuttur. Bir sql server objesini oluşturmak yada silmek için Sql Server PFS ve SGAM page’lerine yazar. Latch dediğimiz Yapılar bu Page’leri hafızada korur.

PFS(Page Free Space): Her page için bir byte’lık bir bilgi tutar. Bu bilgi ilgili Page içerisinde ne kadar boş alan olduğunu ve ne için kullanıldığını tutar. Bir PFS sayfası, yaklaşık olarak 8.088 sayfayı (Yaklaşık 64MB data) kapsar. Herhangi bir veritabanı data file için ilk page PFS dir. Page ile ilgili bir hatada bunu görebiliriz.

“Örnek verecek olursak; 2:1:1 ifadesini yorumlayalım Database id:2 ve 1 numaralı page demektir.”

“Bir diğer örneğimiz 5:3:1 database id:5 file id:3 ve ilk page demektir.”

GAM(Global Allocation Map): GAM page her extent’in kullanım bilgisini tutar. Her extend için bir flag bit kullanılması bir GAM page’in 4GB(6400 extend) bir alanı yönetmesine olanak sağlar.Bir data file’daki ilk GAM page numarası 2’dir. Yani 2:1:2 TempDB’deki ilk GAM page’idir

SGAM(Shared Global Allocation Map):SGAM bu extend’in mixed extend olup olmadığını ve boş page olup olmadığını belirtir.Buradaki flag bit’in “1” olması mixed extent olduğunu ve boş pagelere sahip olduğunu “0” olması ise extent mixed olarak kullanılmadığını veya mixed extend olarak kullanılıyor fakat boş sayfa olmadığını belirtir.GAM gibi 4GB(6400 extend)bir alanı yönetir. Bir data file’daki ilk SGAM page’im numarası 3’tür. Yani 2:1:3 tempDB’nin ilk SGAM page’idir.

TempDB MetaData Contention

Birden fazla session geçici tablo oluşturduğu sırada TempDB’nin sistem tablolarına aynı anda erişmek ister bunun sonucunda MetaData contention oluşur. Bu iş yükü sistem tablolarında gecikmeye sebep olur ve sorgu performansları düşmeye başlar. TempDB üzerindeki darboğazı gidermek ve iş yükünü bölmek için TempDB içerisine yeni file eklenmelidir.

Bu tip durumların yaşanmasını önlemek için yapılması gerekenlere değinecek olursak.

  • Index Rebuild işlemlerinde “sort in tempDB” seçeneği tempDB performansını etkiler.
  • TempDB contention durumunu kontrol etmek ve Microsoft’un “allocation contention” problemini azaltmak için önerilerine buradan ulaşabilirsiniz.
  • Autogrowth özelliği açık olmalıdır.
  • SQL Server’da çalıştırmış olduğumuz sp komutu (sp_whoIsactive @show_sleeping_Spids = 0) ile anlık login olan sorguları kontrol ederken wait_info column içeriğinde görmüş olduğumuz PAGELATCH_EX, PAGELATCH_UP ve CXPACKET türleri TempDB ile doğrudan ilgilidir.

TempDB’nin sistem üzerinde tutulduğu yer bilgisi için sp_Helpdb tempdb komutu kullanılabilir.

TempDB’nin kullandığı disk alanını sys.dm_db_file_space_usage DMV’sini sorgulayarak görebiliriz.

Tempdb içerisinde çok fazla yer kaplayan nesneleri görmek için sys.dm_db_session_space_usage ve sys.dm_db_Task_space_usage kullanılabilir.

 

 

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

İçindekilerVeritabanı Recovery Pending Durumu Nedir?Veritabanı Neden Recover Pending Duruma Düşer?Recovery Pending Durumu Nasıl Çözülür?SonuçKaynaklarVeritabanı 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 işlemleri sürecince devam eder. Ani Sistem […]

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