Üretim tablolarına sütun ekleme


28

SQL Server 2008 R2'deki büyük üretim tablolarına sütun eklemenin en iyi yolu nedir? Microsoft'un çevrimiçi kitaplarına göre:

ALTER TABLE'da belirtilen değişiklikler hemen uygulanır. Değişiklikler tablodaki satırların değiştirilmesini gerektiriyorsa, ALTER TABLE satırları günceller. ALTER TABLE, çok kısa bir SCH-M kilidi gerektiren çevrimiçi dizin işlemleri dışında, değişiklik sırasında tablonun meta verilerini bile referans almadığından emin olmak için tablodaki bir şema değiştirme kilidini aldı.

(Http://msdn.microsoft.com/en-us/library/ms190273.aspx)

Milyonlarca satırı olan büyük bir masada, bu işlem biraz zaman alabilir. Kesinti tek seçenek mi? Bu tür durumlarla başa çıkmanın en iyi yolu nedir?


Yanıtlar:


27

"Değişir"

Satırlara veri eklenmesini gerektirmeyen bir sütun eklerseniz, oldukça hızlı olabilir.

Örneğin, bir int veya char eklemek fiziksel satır hareketleri gerektirir. NULL bitmap'in genişletilmesi gerekmediği sürece varsayılan olmayan null değerine sahip bir varchar eklemek gerekir

Tahmini almak için geri yüklenen bir üretim kopyası üzerinde denemeniz gerekir

Yeni bir tablo oluşturmak, kopyalamak, yeniden adlandırmak milyarlarca satırlık bir tabloya indeksleri ve anahtarları yeniden eklemek zorunda kalırsanız daha uzun sürebilir.

Boşuna bir sütun eklemek için birkaç saniye süren milyar satırlık tabloyu değiştirdim.

Önce bir yedek almalı mıydım?


2
Yedeklemede +1. ve ayrıca yeterli günlük alanınız olduğundan emin olun.
SqlACID

Bir int veya char eklemenin neden fiziksel satır hareketleri gerektirdiğini açıklayabilir misiniz?
sh-beta

5
İkinci satırınızdaki satırlara veri eklemek istemiyor mu demek istediniz?
Ben Brocka

21

Sütun NULL ise, etki ihmal edilebilir düzeyde olmalıdır. Sütun NULL olamaz ve değer ayarlanmalıdır, o zaman oldukça farklı olabilir. Bu durumda ne yapacağım, tek seferde boş olmayan ve varsayılan bir kısıtlama eklemek yerine, her satıra etkili bir şekilde veri eklemek:

  • sütunu NULLable olarak ekle - çoğu durumda hızlı olmalı
  • değerleri varsayılana güncelle
    • Gerekirse bunu gruplar halinde yapabilirsiniz
    • Bunu, bazı satırların varsayılanı alamayacağı koşullu mantık uygulamak için de kullanabilirsiniz.
  • boş değil / varsayılan kısıtları ekle
    • veri hiçbiri NULL olmadığında bu daha hızlı olacaktır, ancak yine de ölçülebilir olması gerekir

@Gbn ile, üretim kopyasını geri yükleyerek ve orada deneyerek test edebileceğinizi kabul edersiniz ... zamanlama konusunda iyi bir fikir edinirsiniz (donanımın biraz benzer olduğunu varsayarak) ve işlem günlüğü üzerindeki etkiyi de görebilirsiniz.


Re son bit: •add the not null/default constraintsBu konuda potansiyel bir sorun olmadığından emin değilim ... MSSQL (hatta 2008R2) boş olmayan bir sütunu değiştirdiğinde, boş bir sütun değiştirirse, üzerine bir iz koyarsanız, gerçekte kapakların altında görebilirsiniz tablonun her satırında tam bir güncelleme yapılıyor, yani update table1 set column1 = column1boşuna doğrulamayı tamamen aptalca bir şekilde yaptığını varsayıyorum. Bu işlem tablonun iki katı büyüklüğünde (sayfalardan önce ve sonra) bir DW tablosu için çok büyük olabilir. Daha önce, bcp verilerini kesmek, kesmek, boş olmayan değişiklikleri yapmak için boş yapmak zorunda

Bunu çözmenin bir yolu bilen varsa, bilmeyi çok isterim ... Buna karşın, Oracle'da null değerinin boş olmamasını değiştirmek, bir kilitleme yapar, sonra null değerinin olmadığını doğrulamak için bir seçim yapar, sonra anlık bir meta veri güncellemesi yapar.

Hey @Mike, bu kendi başına iyi bir potansiyel soru gibi geliyor.
Derek Downey

4

Düşündün mü:

  1. Tablo tanımındaki değişiklikleri içeren yeni bir tablo oluşturma.
  2. Orijinal tablodan seçerek yeni tablo tanımına ekleme.
  3. Orijinal tabloyu _orig olarak yeniden adlandırmak ve ardından yeni tabloyu orijinal tablo adına yeniden adlandırmak.

Buradaki dezavantaj, bu değişikliği yapmak için veritabanında yeterli alana sahip olmanız gerektiğidir. Kirli okumaları önlemek için hala masaya bir okuma kilidi gerekebilir.

Ancak, orijinal tablonun aynı anda erişilmesi için bir şans veya ihtiyaç varsa, son kullanıcılar üzerindeki etkiyi en aza indirirsiniz. Ayrıca kilitleme sürelerini en aza indirmelidir.


Okumak yerine bir yazma kilidine ihtiyacınız olmaz mı ? Kullanıcıların eski tabloda verileri görmesi iyi bir şey; yalnızca arabellek değişimini tamamladığınızda üzerine yazılacak herhangi bir değişiklik yapmalarını istemiyorsunuz.
Tüm İşlemlerden Jon,

Değişikliklerin biraz daha kolay kontrol edilebileceği veri ambarı şapkamla olan düşüncem buydu. Bir OLTP durumunda haklısın, tabloda değişiklik yapılmasını önlemek için bir yazma kilidi gerekir.
RobPaller
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.