Veritabanımız fazla büyüdüğünden, şu anda bazı performans sorunları yaşıyoruz. Son 10 yıldan itibaren depolanan veriler var ve 2 yıldan daha eski verilerin yeni verilerle aynı tablolarda saklanması gerektiğinin bir nedenini görmüyorum.

Veritabanlarını yönetme konusunda çok derin bir deneyimim olmadığından, eski verileri arşivlemenin en iyi yollarını arıyorum.

Bilgi

• Veritabanında toplam 310.000.000 kayıt var.

• Veritabanının sabit diskte 250 GB olması gerekiyor.

• Sunucu sürümü, SQL Server 2005 (90) uyumluluk seviyesine sahip SQL Server 2008'dir, ancak yakında SQL Server 2012'ye yükseltme yapmayı planlıyoruz.

İki olasılık hakkında düşündüm:

Yeni veritabanı

Üretim sunucusundakine benzer bir Veri Tabanı oluşturun ve tüm eski verileri yeni veri tabanına ekleyin.

• Dezavantaj: Bağlantılı sunucuların ortamımızda bulunmasına izin verilmediğinden, gerekirse eski verilere katılmak zor olacaktır.

Tarih Şeması

Üretim veritabanındaki tablolarla aynı şekilde [tarih] için yeni bir şema oluşturun . Tüm eski verileri bu yeni tablolara yeni şemada ekleyin.

• Avantaj: Gelecekte eski verilere ihtiyaç duyulursa kolay birleştirme

• Çözümlerden birini diğerine mi tercih edersiniz?
  • Niye ya?
• Daha iyi bir olasılık var mı?
• Bu görevin kolayca mümkün olabileceği araçlar var mı?
• Başka düşüncen var mı?

Şimdiden teşekkürler

Düzenle

Ek soru:

Yeni oluşturulan arşiv masasında ayrıca birincil / yabancı anahtarlara gerek var mı?

Yoksa sadece sütunları mı içermeli, fakat anahtarları / kısıtları olmadan mı?

Bence birçok sorunuzun cevabı buna bağlı. Hangi performans problemleriniz var? Bir veritabanının sadece 250GB boyutunda büyürken performans sorunları yaşaması olağandışı görünüyor.

Belki de sorgularınız tarih aralığının sadece küçük bir kısmına (örneğin, geçen yıl) ihtiyaç duyulduğunda bile tüm olgu tablosunda tablo taraması yapıyordur? Şema, sorgu ve optimize edilip edilemeyeceğini görmek için başka bir soruda gerçek bir yürütme planı yayınlamayı göz önünde bulundurarak optimize etmek için en önemli olan belirli bir sorgu varsa.

Çözümlerden birini diğerine mi tercih edersiniz?

Genelde tarih veritabanını tercih ederim ve bence Guy bunun cevabında bunun için iyi sebepler açıklıyor .

Bir geçmiş veritabanı için gördüğüm en büyük dezavantaj, şemadan ziyade, arşiv masanız için artık yabancı anahtar kullanamayacağınızdır. Bu senin için iyi olabilir, ama farkında olması gereken bir şey.

Bu yaklaşım için listelediğiniz dezavantaj doğru değildir; Aynı sunucudaki veritabanlarını kolayca sorgulayabileceksiniz ve sorgu iyileştirici genellikle çapraz veritabanı sorgularını çok iyi ele alıyor.

Daha iyi bir olasılık var mı?

Arşiv verilerini düzenli olarak sorgulamanız gerekirse , tabloyu tarihe göre bölümlendirmeyi düşünebilirim . Bununla birlikte, bu, hem olumlu (örneğin, bölümlerin ortadan kaldırılması, daha verimli veri yükleme) hem de negatif (örneğin, daha yavaş singleton arar, paralel sorgularda iplik eğriliği için daha büyük potansiyel) birçok performans çıkarımına yol açabilecek büyük bir değişikliktir. Bu yüzden, yoğun olarak kullanılan bir veri tabanı ise, bu kararı hafifçe vermem.

Yeni oluşturulan arşiv masasında ayrıca birincil / yabancı anahtarlara gerek var mı? Yoksa sadece sütunları mı içermeli, fakat anahtarları / kısıtları olmadan mı?

Sağladıkları veri bütünlüğü avantajlarını elde edebilmeniz için en azından birincil anahtar ve benzersiz dizinlere sahip olmanızı tavsiye ederim. Örneğin, bu, yanlışlıkla bir yıl veri geçmişini tabloya iki kez eklemenizi önler. Ve bir yan fayda olarak, geçmiş tablosunu sorgulamanız gerekirse performansı artırabilir.

Başka düşüncen var mı?

Enterprise sürümünü kullandığınız ve SQL 2008+ sürümüne yükseltmeyi planladığınızdan, bu tablo için veri sıkıştırmayı düşünebilirsiniz . Sıkıştırma disk alanını kesinlikle azaltacaktır, ancak sunucunuzun diskine ve CPU kaynaklarına bağlı olarak, disk G / Ç'yi azaltarak ve bellek kullanımını geliştirerek (aynı anda önbellekte daha fazla veri uyması), okumalar için sorgu performansını artırabilir.

Bağlantılı bir sunucu üzerinden herhangi bir gün bir tarih şeması veya ikinci bir tarihsel veritabanı olmasını tercih ederim. Lisans maliyetlerini düşürür, yönetimi ve sorgulaması kolaydır. Daha sonra daha basit bir şema kullanabilir ve veritabanını küçülten bazı indeksleri bırakabilirsiniz.

Ancak işletme sürümünüze sahip olduğunuzdan, tablolarınızı bölümlere ayırmak için üçüncü bir seçeneğiniz vardır; bunlar, yerleştirildiğinde verileri arşivlemeyi kolaylaştırır ve eski verileri sorgulamak, kullanıcılarınız için şeffaftır ve uygulama değişiklikleri yapmanız gerekmez. .

Benim tecrübeme göre, ikinci bir veri tabanı iki nedenden dolayı tercih edilen seçim olacaktır.

1. Verileri tarihi bir yedekten geri yükleyebilir ve gerek duymadığınız tabloları ve dizinleri bırakabilirsiniz.
2. Bunu raporlama amacıyla farklı bir sunucuya taşıyabilirsiniz, bunun birincil sunucunun kaynaklarını kullanmamanın yararları vardır.

Tüm tarihsel verileri birincil veritabanından silmeniz gerekir, ancak bu zamanlanmış olabilir.

Şimdilik lisansı görmezden geldiğim için zamanımı harcadığım yer orası değil.

IMHO, arşiv veritabanı olan en basit uygulamak ve sürdürmek. Farklı ve gevşek birleşmiş varlıklar. Veri hareketi ve yük / kaynak kontrolleri açık sınırlara sahiptir. Daha iyi performans yönetimi için kolayca farklı bir örneğe veya sunucuya taşınabilir ve maliyet önemli bir sorun değildir. En basit! = En ucuz ya da en az çaba. Aslında biraz daha fazla görevi var ama hepsi iki önemli istisna dışında basit işler.

1. kısıtlamaları zorlama - SQL Server'da çapraz veritabanı kısıtları gibi bir şey yoktur, bu yüzden bunun bir anlaşma bozucu olup olmadığına karar vermeniz gerekir.
2. çapraz veritabanı sorguları, kullanımdan kaldırılan OLEDB'ye hala bağımlı olan dağıtılmış sorgular kullanır. Bu, yeni veri türleriyle ilgili sorunlarla karşılaşabileceğinize ek olarak, performans sorunlarıyla karşılaşırsanız, düzeltilmeleri olası değildir

Arşiv şeması veya sadece arşiv tablosu uygulamak biraz daha karmaşık ancak kullanımı daha kolaydır. Aynı veritabanındaki tüm nesneler erişim denetimlerini çoğaltmanız ve sürdürmeniz gerekmediği anlamına gelir. Performans ayarlama, izleme, sorun giderme vb. İşlemleri kolaylaştırmak için çapraz veritabanı sorguları yapılmaz ...

Masa bölme , mükemmel bir çözümdür ve bir arşiv masasının / şemasının faydalarının çoğunu sağlar, ancak kullanıcılara / sorgulara şeffaflık sağlar. Bu, yeni başlayanlar için kolay olmayan sürekli bakım uygulamak ve gerektiren en karmaşık olduğunu söyledi.

Bazı önemli hususlar:

• Sorgular düzenli olarak tarihsel / soğuk verileri veriyor mu veya soğuk verilere nadiren erişiliyor mu?
• Geçmiş veriler değişmez mi yoksa düzenli olarak güncellenir / silinir mi?
• 310m satırlar, satır boyutuna bağlı olarak "ılımlı" (tümü 1 tabloda olduğu varsayılarak). Satır büyüklüğü verileriniz var mı? Bu 310m satır kaç GB'dir?
• Bu tablonun büyüme hızı nedir?
• Uygulama kodunu ve SQL sorgularını değiştirebiliyor musunuz?

Bunlar, seçtiğiniz çözelti üzerinde önemli bir etkiye sahip olabilecekleri veya belirli çözümlere bile izin vermeyebilecekleri için önemli hususlardır. Örneğin, geçmiş verileriniz düzenli olarak değiştirilirse / güncellenirse (haftada bir kereden fazla), ayrı bir veritabanı kullanmak, bu sorgular için DTC'yi kullanmanız veya işlem güvenliğini elle yönetmeniz gerektiği (her zaman doğru olmasını sağlamak için önemsiz) anlamına gelir. Maliyet, değişken geçmiş verilerden çok daha yüksektir.

Ayrıca, yükseltme yapmayı düşünüyorsanız, 2016'yı ve yeni Streç Veri Tabanı özelliğini göz önünde bulundurun: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Aşağıdaki nedenlerle veritabanını ayrı bir mantıksal veritabanına bölmeyi tercih ederim:

1. Kaynak Gereksinimleri

Bunu ayrı bir veritabanına bölerek, farklı bir sürücüde depolanabilir ve ana üretim verilerine göre farklı bir hızda izlenebilir.

2. Performans

Verileri ayrı bir veritabanına bölerek, ana Üretim veritabanının boyutu azaltılır ve bu da genel performansa yardımcı olur.

3. Basit Yedeklemeler

Arşivlenmiş verilerin yedeklenmesi, ana SQL veritabanındaki 'live / current' kayıtları kadar önemli sayılmaz. Bu, Arşivlenmiş verilerin daha az yedeklenebileceği anlamına gelebilir. Ayrıca, Arşivlenmiş verilerin günlüğe kaydedilmesinin sıralı niteliği nedeniyle, Arşivlenmiş veritabanının bölümlerini bir kez ve sonra bir daha asla yedeklemek mümkün olabilir. Örneğin, arşiv verileri 2014 için Arşiv arşiv veritabanına yazıldığında, bu verilerde bir daha hiçbir değişiklik yapılmayacak.

Not: Birçok sorunun cevabının, durumunuza, verilerin niteliğine ve yaşadığınız performans sorunlarına bağlı olduğunu düşünüyorum.