Aracılığıyla paylaş

SQL Server'da In-Memory OLTP Özelliklerini benimsemenizi planlama

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen Örneği

Bu makalede, SQL Server'da bellek içi özelliklerin benimsenmesinin iş sisteminizin diğer yönlerini etkileme yolları açıklanmaktadır.

Not

A. In-Memory OLTP özelliklerinin benimsenmesi

Aşağıdaki alt bölümlerde, In-Memory özellikleri benimsemeyi ve uygulamayı planlarken dikkate almanız gereken faktörler açıklanmaktadır.

A.1 Önkoşulları

In-Memory özelliklerini kullanmak için önkoşullardan biri, SQL ürününün sürümünü veya hizmet katmanını içerebilir. Bu ve diğer önkoşullar için bkz:

A.2 Etkin bellek miktarını tahmin edin

Sisteminizde bellek için iyileştirilmiş yeni bir tabloyu desteklemek için yeterli etkin bellek var mı?

Microsoft SQL Server

200 GB veri içeren bellek için iyileştirilmiş bir tablo, 200 GB'tan fazla etkin belleğin desteğine ayrılmış olmasını gerektirir. Büyük miktarda veri içeren bellek için iyileştirilmiş bir tablo uygulamadan önce, sunucu bilgisayarınıza eklemeniz gerekebilecek ek etkin bellek miktarını tahmin etmeniz gerekir. Tahmin kılavuzu için bkz:

Azure SQL Yönetilen Örneği için de benzer yönergeler sağlanır:

Azure SQL Veritabanı

Azure SQL Veritabanı bulut hizmetinde barındırılan bir veritabanı için seçtiğiniz hizmet katmanı, veritabanınızın kullanmasına izin verilen etkin bellek miktarını etkiler. Veritabanınızın bellek kullanımını bir uyarı kullanarak izlemeyi planlamanız gerekir. Ayrıntılar için bkz:

Bellek için iyileştirilmiş tablo değişkenleri

Bellek için optimize edilmiş olarak bildirilen bir tablo değişkeni bazen tempdb veritabanında bulunan geleneksel bir #TempTable yerine tercih edilebilir. Tablo değişkenleri, önemli miktarda etkin bellek kullanmadan performans kazanımları sağlayabilir.

A.3 Tablosunun bellek için iyileştirilmiş duruma dönüştürülmesi için çevrimdışı olması gerekir

Bellek için iyileştirilmiş tablolar için bazı ALTER TABLE işlevleri kullanılabilir. Ancak disk tabanlı bir tabloyu bellek için iyileştirilmiş bir tabloya dönüştürmek için ALTER TABLE deyimi düzenleyemezsiniz. Bunun yerine daha el ile uygulanan bir adım kümesi kullanmanız gerekir. Aşağıda, disk tabanlı tablonuzu bellek için iyileştirilmiş olacak şekilde dönüştürmenin çeşitli yolları yer almaktadır.

El ile betik oluşturma

Disk tabanlı tablonuzu bellek için iyileştirilmiş bir tabloya dönüştürmenin bir yolu, gerekli Transact-SQL adımları kendiniz kodlamalısınız.

  1. Uygulama etkinliğini askıya alma.

  2. Tam yedekleme yapın.

  3. Disk tabanlı tablonuzu yeniden adlandırın.

  4. Bellek için iyileştirilmiş yeni tablonuzu oluşturmak için bir CREATE TABLE deyimi oluşturun.

  5. Disk tabanlı tablodan bir alt SELECT ile bellek iyileştirmeli tablonuza INSERT INTO işlemi yapın.

  6. DISK tabanlı tablonuzu DROP.

  7. Başka bir tam yedekleme yapın.

  8. Uygulama etkinliğini sürdür.

Bellek İyileştirme Danışmanı

Bellek İyileştirme Danışmanı aracı, disk tabanlı bir tablonun bellek için iyileştirilmiş bir tabloya dönüştürülmesi için bir betik oluşturabilir. Araç, SQL Server Veri Araçları'nın (SSDT) bir parçası olarak yüklenir.

.dacpac dosyası

SSDT tarafından yönetilen bir .dacpac dosyası kullanarak veritabanınızı yerinde güncelleştirebilirsiniz. SSDT'de, .dacpac dosyasında kodlanmış şemada yapılan değişiklikleri belirtebilirsiniz.

.dacpac dosyalarıyla Veritabanıtüründe bir Visual Studio projesi bağlamında çalışırsınız.

A.4 In-Memory OLTP özelliklerinin uygulamanız için uygun olup olmadığına yönelik kılavuz

In-Memory OLTP özelliklerinin uygulamanızın performansını geliştirip geliştiremeyeceği konusunda rehberlik için bkz:

B. Desteklenmeyen özellikler

Bazı In-Memory OLTP senaryolarında desteklenmeyen özellikler şu konumda açıklanmıştır:

Aşağıdaki alt bölümlerde, desteklenmeyen daha önemli özelliklerden bazıları vurgulanır.

B.1 Veritabanının ANLıK GÖRÜNTÜSÜ

Belirli bir veritabanında belleğe göre iyileştirilmiş bir tablo veya modül ilk kez oluşturulduğunda, artık veritabanının SNAPSHOT’i hiçbir zaman alınamaz. Bunun nedeni şudur:

  • Bellek için iyileştirilmiş ilk öğe, bellek için iyileştirilmiş FILEGROUP'tan son dosyanın bırakılmasının imkansız olmasını sağlar; ve
  • Bellek için optimize edilmiş FILEGROUP içinde dosyası bulunan hiçbir veritabanı ANLIK GÖRÜNTÜ'yü desteklemez.

Normalde anlık görüntü, hızlı test yinelemeleri için kullanışlı olabilir.

B.2 Veritabanları arası sorgular

Bellek için iyileştirilmiş tablolar çapraz veritabanı işlemlerini desteklemez. Bellek için iyileştirilmiş bir tabloya erişen aynı işlemden veya aynı sorgudan başka bir veritabanına erişemezsiniz.

Tablo değişkenleri işlemsel değildir. Bu nedenle, bellek için iyileştirilmiş tablo değişkenleri veritabanları arası sorgularda kullanılabilir.

B.3 READPAST tablo ipucu

Hiçbir sorgu, bellek için iyileştirilmiş herhangi bir tabloya READPAST tablo ipucu uygulayamıyor.

READPAST ipucu, kuyruk işleme gibi aynı küçük satır kümesine erişen ve bunları değiştiren birkaç oturumun bulunduğu senaryolarda yararlıdır.

B.4 RowVersion, Dizi

  • Bellek için iyileştirilmiş bir tablodaki RowVersion için hiçbir sütun etiketlenemez.

  • SEQUENCE bellek ile optimize edilmiş bir tabloda kısıtlamayla kullanılamaz. Örneğin, NEXT VALUE FOR yan tümcesiyle DEFAULT kısıtlaması oluşturamazsınız. SEQUENCEs, INSERT ve UPDATE deyimleriyle kullanılabilir.

C. Yönetim bakımı

Bu bölümde, bellek için iyileştirilmiş tabloların kullanıldığı veritabanı yönetimi farklılıkları açıklanmaktadır.

C.1 Kimlik tohumunu sıfırlama, artış > 1

DBCC CHECKIDENT, bir IDENTITY sütununa yeniden başlangıç değeri atamak için, bellek için optimize edilmiş bir tabloda kullanılamaz.

Artım değeri, bellek için iyileştirilmiş bir tablodaki identity sütunu için tam olarak 1 ile sınırlıdır.

C.2 DBCC CHECKDB bellek için iyileştirilmiş tabloları doğrulayamıyor

DBCC CHECKDB komutu, hedefi bellek için iyileştirilmiş bir tablo olduğunda hiçbir şey yapmaz. Aşağıdaki adımlar geçici bir çözüm olarak sağlanır:

  1. İşlem günlüğünüyedekleyin.

  2. Bellek için iyileştirilmiş FILEGROUP içindeki dosyaları null bir cihaza yedekleyin. Yedekleme işlemi sağlama toplamı doğrulamasını çağırır.

    Bozulma bulunursa sonraki adımlarla devam edin.

  3. Geçici depolama için bellek için iyileştirilmiş tablolarınızdaki verileri disk tabanlı tablolara kopyalayın.

  4. Bellek için iyileştirilmiş FILEGROUP dosyalarını geri yükleyin.

  5. Disk tabanlı tablolarda geçici olarak depoladığınız verileri bellek için iyileştirilmiş tablolara EKLEME.

  6. Verileri geçici olarak tutan disk tabanlı tabloları BıRAKıN.

D. Performans

Bu bölümde, bellek için iyileştirilmiş tabloların mükemmel performansının tam potansiyelin altında tutulabileceği durumlar açıklanmaktadır.

D.1 Endeks dikkate alınması gereken hususlar

Bellek için iyileştirilmiş bir tablodaki tüm dizinler, CREATE TABLE ve ALTER TABLE tabloyla ilgili deyimleri tarafından oluşturulur ve yönetilir. Create INDEX deyimiyle bellek için iyileştirilmiş bir tabloyu hedefleyemezsiniz.

Geleneksel B-ağacı kümelenmemiş dizini, genellikle bellek için optimize edilmiş bir tabloyu ilk kez uyguladığınızda mantıklı ve basit bir seçimdir. Daha sonra, uygulamanızın performansını gördükkten sonra başka bir dizin türünü değiştirmeyi düşünebilirsiniz.

Not

Belgelerde genellikle dizinlere başvuruda B ağacı terimi kullanılır. Rowstore dizinlerinde Veritabanı Altyapısı bir B+ ağacı uygular. Bu, sütun deposu dizinleri veya bellek için iyileştirilmiş tablolardaki dizinler için geçerli değildir. Daha fazla bilgi için SQL Server ve Azure SQL dizin mimarisi ve tasarım kılavuzuna bakın.

Bellek için iyileştirilmiş bir tablo bağlamında iki özel dizin türünün tartışılması gerekir: Karma dizinler ve Sütun deposu dizinleri.

Bellek için iyileştirilmiş tablolardaki dizinlere genel bakış için bkz:

  • Memory-Optimized Tabloları için Dizinleri

Karma dizinler

Karma dizinler, '=' işlecini kullanarak belirli bir satıra tam birincil anahtar değeriyle erişmek için en hızlı biçim olabilir.

  • '!=', '>' veya 'BETWEEN' gibi inexact işleçleri karma dizinle kullanıldığında performansa zarar verir.

  • Anahtar değeri yineleme oranı çok yüksek olursa karma dizin en iyi seçenek olmayabilir.

  • Karma dizininizin kaç demete ihtiyaç duyabileceğini az tahmin etmekten kaçının, böylece tek tek demetler içinde uzun zincirler oluşmasını engelleyebilirsiniz. Ayrıntılar için bkz:

    • Memory-Optimized Tablolar için Karma Dizinleri

Kümelenmemiş columnstore dizinleri

Bellek için iyileştirilmiş tablolar, çevrimiçi işlem işleme veya OLTP olarak adlandırdığımız paradigmada tipik iş işlem verilerinin yüksek aktarım hızını sunar. Columnstore dizinleri, Analyticsolarak adlandırdığımız toplamaların ve benzer işlemlerin yüksek aktarım hızını sunar. Yıllar geçti, OLTP ve Analytics'in ihtiyaçlarını karşılamak için en iyi yaklaşım, yoğun veri hareketi ve bir miktar veri yinelemesi içeren ayrı tablolara sahip olmaktı. Bugün daha basit bir karma çözüm mevcut: bellek için iyileştirilmiş bir tabloda bulunan kolon deposu dizini.

  • columnstore dizini, kümelenmiş dizin olarak bile disk tabanlı bir tablo üzerinde oluşturulabilir. Ancak hafıza için optimize edilmiş bir tabloda sütun deposu dizini küme yapılamaz.

  • Bellek iyileştirmeli bir tablonun LOB veya satır dışı sütunları, tabloda columnstore dizini oluşturulmasını engeller.

  • Bellek için iyileştirilmiş bir tabloda ALTER TABLE deyimi, tabloda columnstore dizini mevcutken yürütülemez.

    • Ağustos 2016 itibarıyla Microsoft'un columnstore dizinini yeniden oluşturma performansını iyileştirmeye yönelik yakın vadeli planları vardır.

D.2 LOB ve satır dışı sütunlar

Büyük nesneler (LOB) varchar(max) gibi türlerdeki sütunlardır. Büyük olasılıkla bellek için iyileştirilmiş bir tabloda birkaç LOB sütunu bulundurmak performansa önemli bir zarar vermez. Ancak veri gereksinimlerinizden daha fazla LOB sütununa sahip olmaktan kaçının. Aynı öneri, satır dışı sütunlar için de geçerlidir. Varchar(512) yeterliyse sütunu nvarchar(3072) olarak tanımlamayın.

LOB ve satır dışı sütunlar hakkında daha fazla bilgi için şu konumdan ulaşabilirsiniz:

E. Yerel prosedürlerin sınırlamaları

Transact-SQL'ın belirli öğeleri, saklı yordamlar dahil yerel olarak derlenmiş T-SQL modüllerinde desteklenmemektedir. Hangi özelliklerin desteklendiği hakkında ayrıntılı bilgi için bkz:

Yerel olarak derlenecek desteklenmeyen özellikleri kullanan bir Transact-SQL modülünü geçirirken dikkat edilmesi gerekenler için bkz:

Transact-SQL'in belirli öğeleriyle ilgili sınırlamaların yanı sıra, yerel olarak derlenmiş T-SQL modüllerinde desteklenen sorgu işleçlerinde de sınırlamalar vardır. Bu sınırlamalar nedeniyle, yerel olarak derlenmiş saklı yordamlar büyük veri kümelerini işleyen analitik sorgular için uygun değildir.

Yerel bir proc'da paralel işleme yok

Paralel işleme, yerel bir proc için herhangi bir sorgu planının parçası olamaz. Yerel procs her zaman tek iş parçacıklı olur.

Birleştirme türleri

Hem hash birleşimi hem de birleştirme birleşimi, yerel bir prosedür için herhangi bir sorgu planının parçası olamaz. İç içe döngü birleşimleri kullanılır.

Karma toplamı yok

Yerel bir proc için sorgu planı bir toplama aşaması gerektirdiğinde, yalnızca akış toplama kullanılabilir. Karma toplama, yerel bir proc için sorgu planında desteklenmez.

  • Çok sayıda satırdan verilerin toplanması gerektiğinde karma toplama daha iyidir.

F. Uygulama tasarımı: İşlemler ve yeniden deneme mantığı

Bellek için iyileştirilmiş bir tablo içeren bir işlem, aynı tabloyu içeren başka bir işleme bağımlı hale gelebilir. Bağımlı işlemlerin sayısı izin verilen üst sınıra ulaşırsa, tüm bağımlı işlemler başarısız olur.

SQL Server 2016'da:

  • İzin verilen maksimum değer sekiz bağımlı işlemdir. Sekiz, aynı zamanda herhangi bir işlemin bağımlı olabileceği işlemlerin sınırıdır.
  • Hata numarası 41839'dur. (SQL Server 2014'te hata numarası 41301'dir.)

Betiklerinize yeniden deneme mantığı ekleyerek Transact-SQL betiklerinizi olası bir işlem hatasına karşı daha sağlam hale getirebilirsiniz. GÜNCELLEME ve DELETE çağrıları sık olduğunda veya bellek için optimize edilmiş tabloya başka bir tablodaki yabancı anahtar tarafından başvurulduğunda, yeniden deneme mantığı daha yararlı olabilir. Ayrıntılar için bkz:

İlgili içerik

  • Last updated on