Veri taşımayı planlamak için iş akışınız nedir?

Pek çok kez bir yazılım geliştirme çabasının sonunda getirildim ve "tamam, tüm bu yeni kodları aldık ve değişecek tabloları ve taşınacak tabloları gerektiriyor" gibi bir şey söylendi .

Her defasında tek seferlik, kalçadan ateş, en iyi tahmin senaryosu gibi görünüyor. Bunun bir DBA olarak belirlenmiş en zayıf yeteneğim olduğunu hissediyorum.

Veri taşıma işlemlerine yaklaşmak, yönetmek ve test etmek için bazı kalıplara girmek istiyorum .

Lütfen beni en iyi uygulamalar ve / veya bu alanda daha iyi olmama yardımcı olacak öğrenme materyali alabileceğim yerle ilgili olarak belirtin.

Her yaptığımda, iki geçiş için gittik ...

1. anlık görüntü almak ve farklı bir sunucu üzerinde çalışmak, geçiş için ne yapılması gerektiğini belirlemek için bunu kullanın ve komut dosyası.
2. betiği ellerinde bulundurduktan sonra, anlık görüntü test sistemine geri yüklenir ve gereken süre içinde çalışıp çalışmayacağını görmek için zamanlanır veya yapabileceklerine kadar ayarlanır ve değiştirilir.
3. paydaşların test sistemindeki verilerde hiçbir şeyin yanlış görünmediğini belirtmelerini isteyin.

Ardından, bir hafta sonu boyunca planlanmış bir kesinti yaşarsınız:

1. Cuma gecesi, veritabanını kullanan sistemler kapatılır, tam bir soğuk yedekleme yapılır ve komut dosyaları veriyi taşımak / değiştirmek / ne olursa olsun çalıştırılır
2. Sistemler bazı özel adresler altında ya da bir şekilde kuruluyor, böylece kabul testi için paydaşların dışında kimseye açık değil
3. Eğer paydaşlar onaylarsa, sistem çevrimiçi duruma geçer ve kamuya açıklanır; değilse, veritabanı Cuma gecesi yapılan yedeklemeden geri yüklenir ve işleme yeniden başlarsınız.

Bizim programımıza göre, veritabanı çalışanları genellikle yedekleme ve taşıma komut dosyalarını çalıştırmak için Cuma günü sabah 10'dan akşam 10'a kadar vardı, bu yüzden hedefimiz 8 saatin altında koşmaktı (~ 6'sı yedek). Testlerimiz ve düzeltmelerimiz için paydaşlarımıza yayınlanmadan önce biraz zamanınız olacak.

Paydaşlara zaman pencereleri önceden verildi, bu yüzden hafta sonlarını pencerenin başında test için açık bıraktıklarını biliyorlardı. Ayrıca, genellikle Pazar öğleden sonraları, herkesin imzalamaması durumunda geri çekilmeye başlamamız gereken pencerenin sonuna da söylenecek.

Oh, ve elbette ... eğer herhangi biri bir kabul testi sırasında bir değişiklik yaptıysa ve bir değişiklik yaptıysak, bu tüm paydaşların imzaları geçersiz sayıldı ve yeniden test etmek zorunda kaldılar ... sorunları aramaya ve düzeltmeleri toplu iş olarak yapmaları için bir süre ayırmaya çalışırdık, her seferinde bir tane uygulamak yerine.

Neyse ki, önemli bir aksama süresinin bulunmadığı bu durumlardan sadece birinde yaşadığım zamanlar, geçirdiğim sistemler komut dosyalarından besleniyordu, kullanıcı girdisinden değil, böylece iki paralel sistemin çalışmasını ve değiştirmelerini sağlayabildim. işler imzalandığında. (sadece bir keresinde bir sorun vardı, patronum tam bir yedekleme almamız konusunda ısrar ettiğinde, her şeyin farklı bir IP’de hala çevrimiçi olacağının farkında değildi) ... Kötü bir gün 5 saat kesinti oldu.)

Her şey veritabanını destekleyen donanımın gücüne ve sistemin kullanılabilirliği ile ilgili anlaşmalara göre verilerin hacmine bağlıdır. Bir kesinti var mı yoksa hepsi çevrimiçi ortamda mı yapılmalı? Verileri temizlemeye başlayın, eski satırları mümkün olduğunca silerek temizleyin. Bu başlı başına bir proje. Veriler temiz ve değerliyse, kullanıcının çalışmama süresi konusunda karar vermesini sağlayın. Arıza süresi mevcut ise, güncel koleksiyonun oluşturulması için mevcut veriler üzerinde uygulanması gereken bilinen bir dönüşüm olması durumunda oldukça basittir. Aksi takdirde - veya çok az - aksama süresi varsa, meydan okuma başlar. Oracle bunu çevrimiçi tablo yeniden tanımlaması ve - 11g sürümündeki yeni yeniden tanımlama gibi yeni yöntemlerle destekliyor. Çevrimiçi tablo yeniden tanımlaması ile tabloları yeni formlarını almaya hazırlayabilirsiniz. Bu, uygulama tablonun eski formunda çalışırken yapılabilir. Hepsi hazırsa, tablonun yeni biçimine geçebilirsiniz [s]. Bu aynı zamanda yeni uygulama kodunu sunma anı olacak ve aynı zamanda yeni uygulamayı uygulamaya koymak için gereken aksama süresinin başlangıcını da işaretleyecektir. Daha eski geçmiş veriler, canlı veriler taşınmadan önce hazırlanabilir ve Oracle Golden Gate gibi araçlar kullanılarak senkronize tutulabilir. Böyle bir senaryoda, eski veritabanının rolünü devralan yeni bir veritabanı oluşturursunuz. Herhangi bir tablo değişikliği gerekmiyorsa, Edition tabanlı yeniden tanımlamalar daha uygundur. Dikkate alınması gereken birçok seçenek var ve her zaman işe yarayan iyi bir kural vermenin zor olduğunu düşünüyorum. Bu aynı zamanda yeni uygulama kodunu sunma anı olacak ve aynı zamanda yeni uygulamayı uygulamaya koymak için gereken aksama süresinin başlangıcını da işaretleyecektir. Daha eski geçmiş veriler, canlı veriler taşınmadan önce hazırlanabilir ve Oracle Golden Gate gibi araçlar kullanılarak senkronize tutulabilir. Böyle bir senaryoda, eski veritabanının rolünü devralan yeni bir veritabanı oluşturursunuz. Herhangi bir tablo değişikliği gerekmiyorsa, Edition tabanlı yeniden tanımlamalar daha uygundur. Dikkate alınması gereken birçok seçenek var ve her zaman işe yarayan iyi bir kural vermenin zor olduğunu düşünüyorum. Bu aynı zamanda yeni uygulama kodunu sunma anı olacak ve aynı zamanda yeni uygulamayı uygulamaya koymak için gereken aksama süresinin başlangıcını da işaretleyecektir. Daha eski geçmiş veriler, canlı veriler taşınmadan önce hazırlanabilir ve Oracle Golden Gate gibi araçlar kullanılarak senkronize tutulabilir. Böyle bir senaryoda, eski veritabanının rolünü devralan yeni bir veritabanı oluşturursunuz. Herhangi bir tablo değişikliği gerekmiyorsa, Edition tabanlı yeniden tanımlamalar daha uygundur. Dikkate alınması gereken birçok seçenek var ve her zaman işe yarayan iyi bir kural vermenin zor olduğunu düşünüyorum. Daha eski geçmiş veriler, canlı veriler taşınmadan önce hazırlanabilir ve Oracle Golden Gate gibi araçlar kullanılarak senkronize tutulabilir. Böyle bir senaryoda, eski veritabanının rolünü devralan yeni bir veritabanı oluşturursunuz. Herhangi bir tablo değişikliği gerekmiyorsa, Edition tabanlı yeniden tanımlamalar daha uygundur. Dikkate alınması gereken birçok seçenek var ve her zaman işe yarayan iyi bir kural vermenin zor olduğunu düşünüyorum. Daha eski geçmiş veriler, canlı veriler taşınmadan önce hazırlanabilir ve Oracle Golden Gate gibi araçlar kullanılarak senkronize tutulabilir. Böyle bir senaryoda, eski veritabanının rolünü devralan yeni bir veritabanı oluşturursunuz. Herhangi bir tablo değişikliği gerekmiyorsa, Edition tabanlı yeniden tanımlamalar daha uygundur. Dikkate alınması gereken birçok seçenek var ve her zaman işe yarayan iyi bir kural vermenin zor olduğunu düşünüyorum.

Bu ilginç bir konu, Ronald.

Şimdiye kadar iyi cevaplar. Düşünmek için birkaç puan daha ekleyeceğim.

İlk olarak, basit SQL DML ile geçişlerinizi yapabiliyorsanız, tüm satırların başarıyla işlendiğinden emin olmak için büyük ölçüde SQL motorunuza güvenebilirsiniz. Bununla birlikte, göçün bir kısmının biraz daha karmaşık olduğu yerlerde göçlere katıldım - veriler yeni bir yapıya taşınırken gerçek veri dönüşümleri vardı. Bu gibi durumlarda, aşağıdakileri işleyebilecek bir sürecin olması önemlidir:

• İşlenen kayıtlara karşı kayıtları sayın.
• Dönüşüm sırasındaki hataları saptayın ve onlarla dönüşümün devam etmesine izin verecek şekilde düzeltin ve bir düzeltme belirledikten sonra "kötü" kayıtların yeniden işlenmesine izin verin.
• Rekor sayımları "kötü" kayıtları içermelidir - yani records-in = records-out-good + bad-records
• Dönüşüm değişiklikleriniz rekor sayıları değiştirirse (örneğin bir girdi kaydı birden fazla çıktı kaydına dönüşürse), elde edeceğiniz çıktı kayıt sayısını tahmin etmenin bir yolu vardır ve ardından sonuçlarınızı bu sayıya göre test eder.

Ekleyeceğim bir diğer nokta ise, işler planlandığı gibi gitmediğinde ne yapacağınızla ilgili bir planın olmasının önemli olduğudur. Bu gerçekten bir bütün olarak konuşlandırmanın bir fonksiyonudur, ancak değinmeye değeceğini düşündüğüm kadar sıkça anlaşılmış görünüyor.

Nasıl yapılacağına genel bakış

İle başlamak

• Test / UAT / "çalışma DB" nde "after" veritabanına sahipsiniz
• Üretimde "önce" veritabanına sahipsiniz. Bu nedenle, bir yerde üretimin bir kopyasını oluşturmak için kullanın = "Reference DB". Ve "script test DB" olarak başka
• Ayrıca ALTER'ler vb. İle birlikte bir sürü geliştirme betiği olduğunu da umuyorum. Eğer öyleyse, geliştirme betiğinizin uygulandığı başka bir üretim kopyası temiz ve sırayla yararlıdır: "DB'yi değiştirin"

Ardından, Red Gate'i düşürün araçları veya Embarcadero SQL Change manager gibi bir şeyi karşılaştırın . Onsuz kolayca taşınamazsınız. Maliyet, harcanan zaman miktarına göre önemsizdir. Ve en önemlisi, oluşturulan komut dosyaları tek bir işlemde değişiklik yapar ve bu da temiz bir dağıtım anlamına gelir

Şimdi,

• "referans" ve "değişiklik" arasında karşılaştırma yapan araçları kullanarak değişiklik ve geri alma komut dosyaları oluşturun
• değişiklik betiğini "script test" e uygulayın ve "working DB" ile tekrar karşılaştırın
• geri alma komut dosyasını "komut dosyası testi" ne uygulayın ve geri "ile karşılaştırın ve" çalışma DB "ile yeniden karşılaştırın

Artık, ne zaman uygulanacak güvenli + test edilmiş değişiklik ve geri alma komut dosyalarına sahipsiniz.

Ve tabii ki herhangi bir değişiklik yapmadan önce veritabanını yedeklersiniz çünkü istatistiksel olarak bok her zaman gerçekleşir.

Red Gate araçları ayrıca kaynak kontrolü altındaki bir klasörle de karşılaştırılabilir. Ardından kaynak kontrolümüzdeki ALTER'leri vb. Fiili değişiklik kodlarına ayrı olarak yakalarız.