Quy trình công việc của bạn để lập kế hoạch di chuyển dữ liệu là gì?

Vì vậy, nhiều lần tôi đã được đưa vào khi kết thúc nỗ lực phát triển phần mềm và được thông báo điều gì đó như "được rồi, chúng tôi đã có tất cả mã mới này và nó yêu cầu các bảng phải thay đổi và dữ liệu phải được di chuyển".

Có vẻ như mỗi lần nó là một kịch bản một lần, bắn từ hông, đoán đúng nhất. Tôi cảm thấy như đây là kỹ năng yếu nhất của tôi khi là một DBA.

Tôi muốn tham gia vào một số mẫu để tiếp cận, quản lý và kiểm tra di chuyển dữ liệu .

Vui lòng cho tôi biết một số thực tiễn tốt nhất và / hoặc nơi tôi có thể lấy tài liệu học tập để giúp tôi trở nên tốt hơn trong lĩnh vực này.

Mỗi lần tôi làm điều đó, chúng tôi đã đi hai lần ...

1. chụp ảnh nhanh và làm việc trên một máy chủ khác, sử dụng nó để xác định những gì phải được thực hiện cho việc di chuyển và kịch bản nó.
2. một khi họ có tập lệnh trong tay, snapshop được khôi phục trên hệ thống kiểm tra và đã đến lúc xem nó sẽ chạy trong thời gian cần thiết hay đã được điều chỉnh và sửa đổi cho đến khi có thể.
3. có các bên liên quan ký tắt rằng không có gì sai với dữ liệu trên hệ thống kiểm tra.

Sau đó, vào cuối tuần, bạn có một lần mất điện theo lịch trình:

1. Tối thứ sáu, các hệ thống sử dụng cơ sở dữ liệu được đưa xuống, sao lưu toàn bộ lạnh được thực hiện và các tập lệnh được chạy để di chuyển / sửa đổi / bất cứ điều gì vào dữ liệu
2. Các hệ thống được đưa lên dưới một số địa chỉ riêng hoặc bằng cách nào đó được thiết lập để nó không mở cho bất kỳ ai trừ các bên liên quan để thử nghiệm chấp nhận
3. Nếu các bên liên quan chấp thuận, hệ thống sẽ đưa trực tuyến và công khai; nếu không, cơ sở dữ liệu sẽ được khôi phục từ bản sao lưu được thực hiện vào tối thứ Sáu và bạn bắt đầu lại quá trình.

Với lịch trình của chúng tôi, mọi người trong cơ sở dữ liệu thường có từ 6 giờ tối Thứ Sáu đến 10 giờ sáng Thứ Bảy để chạy các tập lệnh sao lưu và di chuyển, vì vậy mục tiêu của chúng tôi là họ sẽ chạy trong vòng dưới 8 giờ (~ 6 trong số đó là các bản sao lưu), vì vậy chúng tôi ' d có một chút thời gian để thử nghiệm và sửa chữa của chúng tôi trước khi nó được phát hành cho các bên liên quan.

Các bên liên quan đã được đưa ra các cửa sổ thời gian của họ trước, vì vậy họ biết để lại cuối tuần của họ mở để thử nghiệm ở đầu cửa sổ. Họ cũng sẽ được thông báo về phần cuối của cửa sổ, điển hình là chiều Chủ nhật, nếu mọi người không đăng xuất, chúng tôi sẽ phải bắt đầu quay lại.

Ồ, và tất nhiên ... nếu ai đó có thay đổi trong các thử nghiệm chấp nhận và chúng tôi đã thực hiện thay đổi, điều đó có nghĩa là tất cả các lần đăng xuất của các bên liên quan đều bị hủy và họ phải kiểm tra lại ... vì vậy chúng tôi sẽ cố gắng cung cấp cho họ tất cả thời gian để tìm kiếm các vấn đề và chạy bất kỳ sự điều chỉnh nào theo từng đợt, thay vì áp dụng chúng một lần.

May mắn thay, lần duy nhất tôi gặp phải một trong những tình huống mà chúng tôi không thể có thời gian chết đáng kể, các sytems tôi đang di chuyển được cung cấp từ các tập lệnh, không phải đầu vào của người dùng, vì vậy tôi có thể có hai hệ thống song song hoạt động và trao đổi chúng khi mọi thứ đã được ký kết (chỉ một lần có vấn đề, khi sếp của tôi khăng khăng rằng chúng tôi sao lưu toàn bộ, không hiểu rằng toàn bộ sự việc sẽ vẫn trực tuyến ở một IP khác ... vì vậy, thời gian ngừng hoạt động là 5 phút ngày tồi tệ đã trở thành mất điện 5 giờ.)

Tất cả phụ thuộc vào khối lượng dữ liệu so với sức mạnh của phần cứng hỗ trợ cơ sở dữ liệu và các thỏa thuận về tính khả dụng của hệ thống. Bạn có tình cờ có một số thời gian chết hoặc tất cả nên được thực hiện trực tuyến? Bắt đầu làm sạch dữ liệu, xóa sạch các hàng lỗi thời hết mức có thể. Đây là một dự án trên chính nó. Nếu dữ liệu sạch và có giá trị, hãy để người dùng quyết định về thời gian chết. Nếu thời gian chết có sẵn thì nó khá đơn giản, nếu chúng là một phép biến đổi đã biết nên được áp dụng trên dữ liệu hiện có để tạo thành bộ sưu tập được cập nhật. Nếu không có - hoặc rất ít - thời gian chết cho phép thử thách bắt đầu. Oracle hỗ trợ điều này theo một số cách như xác định lại bảng trực tuyến và - mới trong định nghĩa lại dựa trên phiên bản 11g. Với định nghĩa lại bảng trực tuyến, bạn có thể chuẩn bị các bảng để có dạng mới. Điều này có thể được thực hiện trong khi ứng dụng đang chạy trên dạng cũ của bảng [s]. Nếu tất cả đều sẵn sàng, bạn có thể chuyển sang dạng mới của bảng [s]. Đây cũng sẽ là thời điểm để giới thiệu mã ứng dụng mới và đồng thời đánh dấu sự khởi đầu của thời gian chết cần thiết để đưa ứng dụng mới vào vị trí. Dữ liệu lịch sử cũ hơn có thể được chuẩn bị trước khi dữ liệu trực tiếp di chuyển và được giữ đồng bộ bằng các công cụ như Oracle Golden Gate. Trong một kịch bản như vậy, bạn xây dựng một cơ sở dữ liệu mới có vai trò của cơ sở dữ liệu cũ một cách hiệu quả. Định nghĩa lại dựa trên phiên bản phù hợp hơn nếu không cần thay đổi bảng. Có rất nhiều lựa chọn để xem xét và tôi nghĩ rằng thật khó để đưa ra một quy tắc tốt luôn luôn hoạt động. Đây cũng sẽ là thời điểm để giới thiệu mã ứng dụng mới và đồng thời đánh dấu sự khởi đầu của thời gian chết cần thiết để đưa ứng dụng mới vào vị trí. Dữ liệu lịch sử cũ hơn có thể được chuẩn bị trước khi dữ liệu trực tiếp di chuyển và được giữ đồng bộ bằng các công cụ như Oracle Golden Gate. Trong một kịch bản như vậy, bạn xây dựng một cơ sở dữ liệu mới có vai trò của cơ sở dữ liệu cũ một cách hiệu quả. Định nghĩa lại dựa trên phiên bản phù hợp hơn nếu không cần thay đổi bảng. Có rất nhiều lựa chọn để xem xét và tôi nghĩ rằng thật khó để đưa ra một quy tắc tốt luôn luôn hoạt động. Đây cũng sẽ là thời điểm để giới thiệu mã ứng dụng mới và đồng thời đánh dấu sự khởi đầu của thời gian chết cần thiết để đưa ứng dụng mới vào vị trí. Dữ liệu lịch sử cũ hơn có thể được chuẩn bị trước khi dữ liệu trực tiếp di chuyển và được giữ đồng bộ bằng các công cụ như Oracle Golden Gate. Trong một kịch bản như vậy, bạn xây dựng một cơ sở dữ liệu mới có vai trò của cơ sở dữ liệu cũ một cách hiệu quả. Định nghĩa lại dựa trên phiên bản phù hợp hơn nếu không cần thay đổi bảng. Có rất nhiều lựa chọn để xem xét và tôi nghĩ rằng thật khó để đưa ra một quy tắc tốt luôn luôn hoạt động. Dữ liệu lịch sử cũ hơn có thể được chuẩn bị trước khi dữ liệu trực tiếp di chuyển và được giữ đồng bộ bằng các công cụ như Oracle Golden Gate. Trong một kịch bản như vậy, bạn xây dựng một cơ sở dữ liệu mới có vai trò của cơ sở dữ liệu cũ một cách hiệu quả. Định nghĩa lại dựa trên phiên bản phù hợp hơn nếu không cần thay đổi bảng. Có rất nhiều lựa chọn để xem xét và tôi nghĩ rằng thật khó để đưa ra một quy tắc tốt luôn luôn hoạt động. Dữ liệu lịch sử cũ hơn có thể được chuẩn bị trước khi dữ liệu trực tiếp di chuyển và được giữ đồng bộ bằng các công cụ như Oracle Golden Gate. Trong một kịch bản như vậy, bạn xây dựng một cơ sở dữ liệu mới có vai trò của cơ sở dữ liệu cũ một cách hiệu quả. Định nghĩa lại dựa trên phiên bản phù hợp hơn nếu không cần thay đổi bảng. Có rất nhiều lựa chọn để xem xét và tôi nghĩ rằng thật khó để đưa ra một quy tắc tốt luôn luôn hoạt động.

Đó là một chủ đề thú vị, Ronald.

Câu trả lời tốt cho đến nay. Tôi sẽ thêm một vài điểm để xem xét.

Đầu tiên, khi bạn có thể thực hiện việc di chuyển của mình với SQL DML đơn giản, bạn có thể chủ yếu dựa vào công cụ SQL của mình để đảm bảo tất cả các hàng được xử lý thành công. Tuy nhiên, tôi đã tham gia vào việc di chuyển, trong đó, một số di chuyển phức tạp hơn một chút - có những biến đổi dữ liệu thực tế khi dữ liệu được chuyển sang cấu trúc mới. Trong những trường hợp này, điều quan trọng là bạn có một quy trình có thể xử lý các mục sau:

• Đếm hồ sơ trong so với hồ sơ được xử lý.
• Phát hiện lỗi trong quá trình chuyển đổi và xử lý chúng theo cách cho phép chuyển đổi tiếp tục và cho phép xử lý lại các bản ghi "xấu" sau khi bạn xác định được cách khắc phục.
• Số lượng hồ sơ phải bao gồm các hồ sơ "xấu" - tức là records-in = records-out-good + bad-records
• Nếu phép chuyển đổi của bạn thay đổi số lượng bản ghi (chẳng hạn, một bản ghi đầu vào trở thành nhiều hơn một bản ghi đầu ra) có cách dự đoán số lượng bản ghi đầu ra mà bạn sẽ kết thúc và sau đó kiểm tra kết quả của bạn theo số đó.

Điểm khác tôi muốn nói thêm là điều quan trọng là phải có kế hoạch cho những gì bạn sẽ làm nếu / khi mọi thứ không diễn ra theo kế hoạch. Đây thực sự là một chức năng của việc triển khai nói chung, nhưng nó dường như được che đậy thường xuyên đến mức tôi nghĩ rằng nó đáng để đề cập.

Tổng quan về cách làm

Để bắt đầu với

• Bạn có cơ sở dữ liệu "sau" trong test / UAT / bất cứ điều gì "DB hoạt động"
• Bạn có cơ sở dữ liệu "trước" trong sản xuất. Vì vậy, sử dụng nó để tạo một bản sao của sản xuất ở đâu đó = "DB tham chiếu". Và một cái khác là "kịch bản thử nghiệm DB"
• Tôi cũng hy vọng bạn có một loạt các tập lệnh phát triển với ALTER của mình, v.v. Nếu vậy, một bản sao sản xuất khác với tập lệnh phát triển của bạn được áp dụng, sạch sẽ và theo thứ tự là hữu ích = "thay đổi DB"

Tiếp theo, tải xuống Red Gate So sánh các công cụ hoặc một cái gì đó như Trình quản lý thay đổi SQL của Embarcadero . Bạn không thể dễ dàng di chuyển mà không có nó. Chi phí là không đáng kể với số lượng thời gian tiết kiệm. Và quan trọng nhất, các tập lệnh được tạo sẽ tạo ra các thay đổi trong một giao dịch, có nghĩa là triển khai sạch

Hiện nay,

• tạo tập lệnh thay đổi và khôi phục bằng cách sử dụng các công cụ so sánh giữa "tham chiếu" và "thay đổi"
• áp dụng tập lệnh thay đổi cho "kiểm tra tập lệnh" và so sánh lại với "DB hoạt động"
• áp dụng tập lệnh rollback cho "kiểm tra tập lệnh" và so sánh lại với "và so sánh lại với" DB hoạt động "

Bây giờ, bạn có các kịch bản thay đổi và khôi phục được kiểm tra an toàn + được áp dụng bất cứ khi nào.

Và tất nhiên, bạn sao lưu cơ sở dữ liệu trước khi có bất kỳ thay đổi nào vì cuối cùng shit sẽ luôn xảy ra.

Các công cụ Red Gate cũng có thể so sánh với một thư mục được kiểm soát nguồn. Sau đó, chúng tôi nắm bắt các ALTER vv trong kiểm soát nguồn riêng biệt với các tập lệnh thay đổi thực tế.