Thực tiễn tốt nhất để quản lý thay đổi với các chỉ mục

Cửa hàng CNTT của chúng tôi trước tiên bắt đầu xây dựng một nhóm DBA. Tất cả chúng tôi (bao gồm cả tôi) đã đến từ thế giới kiến ​​trúc / phát triển ứng dụng, vì vậy thế giới DBA vẫn còn khá mới mẻ đối với chúng tôi.

Cùng với việc xây dựng một nhóm DBA, chúng tôi đang tìm cách xây dựng các quy trình và quy trình quản lý thay đổi (hy vọng dựa trên các thực tiễn tốt nhất) khi chúng tôi cần di chuyển các thay đổi.

Tôi đã tìm thấy bài đăng sau đây hữu ích cho phần lớn kích hoạt, thủ tục được lưu trữ và / hoặc thay đổi DDL. Nhưng nó không nhất thiết phải giải quyết các chỉ mục hoặc cơ sở dữ liệu nhà cung cấp.

Chúng tôi có sự kết hợp của cả cơ sở dữ liệu của riêng mình và nhà cung cấp. Trong trường hợp của chúng tôi, một số nhà cung cấp (mặc dù không phải tất cả) đang làm việc với công ty chúng tôi để xây dựng (các) cơ sở dữ liệu và ứng dụng. Chúng tôi đang trong quá trình kiểm tra hiệu năng các ứng dụng của mình ngay bây giờ trước khi chúng "hoạt động". Do đó, chúng tôi đang phân tích các chỉ số (hoặc thiếu chúng) khá nhiều.

Khi chúng tôi đi qua các chỉ mục mà chúng tôi cảm thấy nên được thực hiện, làm thế nào để chúng tôi xử lý tốt nhất việc quản lý thay đổi liên quan đến các chỉ số này, cho cả cơ sở dữ liệu của chúng tôi cũng như cho bất kỳ nhà cung cấp nào?

Bạn làm gì trong cửa hàng của bạn? Tôi ít lo lắng về các công cụ sau đó về quy trình.

EDIT: Cho đến nay, tôi đánh giá cao phản hồi, bình luận và câu trả lời cho câu hỏi này. Tôi đã nhận thấy rằng một số câu trả lời là một công cụ bit cụ thể. Tôi đang tìm kiếm các thực hành "bất khả tri" hơn, nếu điều đó có thể có.

Tuy nhiên, nếu không thể biết được, thì đối với các bộ công cụ, chúng tôi chủ yếu sử dụng IBM DB2 LUW (và thực tế là trên AIX). Chúng tôi có một số DB2 trên Windows và DB2 cho i (i5 / OS của IBM), nhưng chúng tôi chủ yếu là AIX DB2. Chúng tôi sử dụng kiểm soát nguồn, cụ thể là Subversion.

Một lần nữa, tìm kiếm các thực tiễn tốt nhất nói chung, nhưng ở trên là những gì chúng tôi sử dụng sẽ được nhà cung cấp cụ thể.

EDIT: Quyết định hiện tại: Chúng tôi dự định theo dõi lý luận cũng như những thay đổi của chúng tôi. Vì vậy, chúng tôi sẽ mở một vấn đề trong phần mềm theo dõi vấn đề của chúng tôi (mà trong trường hợp của chúng tôi là JIRA). Bây giờ chúng ta có thể thêm vào tài liệu về mức độ ưu tiên của thay đổi, dữ liệu sao lưu thay đổi sẽ là gì, thay đổi và kết quả của thay đổi từ môi trường khác nơi thử nghiệm thay đổi.

Sau đó, chúng tôi cũng có ý định theo dõi các thay đổi của chúng tôi trong các tập lệnh trong SVN (giống như được đề xuất bên dưới). Bằng cách này chúng ta có thể theo dõi phiên bản của những gì tồn tại ở đâu. Điều này có thể được ghi lại trong vấn đề JIRA của chúng tôi (và trong bất kỳ phần mềm kiểm toán nào khác mà chúng tôi sử dụng, tức là các liên kết đã dán). Chúng ta có thể biết chắc chắn hơn những thay đổi đã đi đến môi trường nào và tại sao. Sau đó, chúng tôi cũng có thể theo dõi nếu chỉ mục là thứ chúng tôi đã thêm ngoài việc triển khai của nhà cung cấp hoặc trước khi triển khai, v.v.)

Tôi thực sự khuyên bạn nên đối xử với cơ sở dữ liệu của mình về cơ bản giống như cách bạn đối xử với mã ứng dụng của mình. Bạn có thể kịch bản cơ sở dữ liệu của mình ra các bộ phận cấu thành và kiểm tra chúng thành kiểm soát nguồn và sau đó sử dụng cùng nhãn & phiên bản mà bạn sử dụng cho các ứng dụng của mình.

Để đưa các đối tượng vào kiểm soát nguồn, có một số công cụ bạn có thể sử dụng. Microsoft có một công cụ có biệt danh là Data Dude. Nó hoạt động với Visual Studio. Họ cũng đang chuẩn bị phát hành một công cụ mới có tên SQL Server Database Tools (SSDT), một lần nữa, hoạt động với Visual Studio. Công ty của tôi, Red Gate Software, tạo ra một công cụ hoạt động với SSMS được gọi là SQL Source Control.

Về mặt quy trình, tôi đã viết một vài chương cho cuốn sách Hướng dẫn phát triển đội đỏ . Nó có sẵn dưới dạng tải xuống miễn phí (hoặc nếu bạn muốn giết một cái cây, bạn có thể lấy một cây từ Amazon). Tôi đi sâu vào nhiều chi tiết hơn về làm việc với cơ sở dữ liệu trong các nhóm phát triển ở đó.

1. Chúng tôi duy trì các tập lệnh cơ sở dữ liệu như là một phần của cơ sở mã ứng dụng được duy trì dưới sự kiểm soát phiên bản. Tuy nhiên, chúng tôi sử dụng các "quy trình" khác nhau để phát triển và sản xuất mã

2. Phát triển chúng tôi duy trì các tập lệnh sau:

   • base.sql - tạo các bảng lược đồ và dữ liệu mẫu
   • stagingchanges.sql - thực hiện các thay đổi đối với cơ sở cho môi trường dàn dựng, chủ yếu là địa chỉ email, đường dẫn và các tài sản khác có thể thay đổi
   • prodchanges.sql - thực hiện các thay đổi đối với base.sql để triển khai sản xuất. Đối với các dự án mới, chúng tôi thường kiểm tra chúng trong môi trường sản xuất thực tế

3. Bảo trì

   • base.sql - phiên bản vệ sinh của cơ sở dữ liệu sản xuất
   • stagingchanges.sql và prodchanges.sql - như trên
   • changerequest.sql (thường có id của yêu cầu thay đổi) áp dụng mọi thay đổi lược đồ cho yêu cầu thay đổi hiện tại mà chúng tôi đang thực hiện
   • changerequest-rollback.sql - đảo ngược các thay đổi được thực hiện cho yêu cầu thay đổi và đặt lại cơ sở dữ liệu trở lại sản xuất
   • lưu trữ (thư mục) cho các kịch bản yêu cầu thay đổi trước đó

Vì vậy, trong chế độ bảo trì, tất cả những gì chúng ta cần làm là áp dụng tập lệnh changerequest.sql trong quá trình triển khai vào sản xuất

Ở trong không gian kiểm soát phiên bản cơ sở dữ liệu trong 5 năm (với tư cách là giám đốc quản lý sản phẩm tại DBmaestro ) và đã làm việc như một DBA trong hơn hai thập kỷ, tôi có thể nói với bạn một thực tế đơn giản là bạn không thể đối xử với các đối tượng cơ sở dữ liệu khi bạn đối xử với Java, C # hoặc các tập tin khác.

Có nhiều lý do và tôi sẽ nêu một vài lý do:

• Các tệp được lưu trữ cục bộ trên PC của nhà phát triển và sự thay đổi mà anh ta
  thực hiện không ảnh hưởng đến các nhà phát triển khác. Tương tự như vậy, nhà phát triển không bị ảnh hưởng bởi những thay đổi được thực hiện bởi đồng nghiệp của cô. Trong cơ sở dữ liệu, đây
  không phải là trường hợp và các nhà phát triển chia sẻ cùng một
  môi trường cơ sở dữ liệu , do đó, bất kỳ thay đổi nào được cam kết với cơ sở dữ liệu đều ảnh hưởng đến người khác.
• Xuất bản thay đổi mã được thực hiện bằng cách sử dụng Đăng ký / Gửi thay đổi / vv (tùy thuộc vào công cụ kiểm soát nguồn nào bạn sử dụng). Tại thời điểm đó, mã từ thư mục cục bộ của nhà phát triển được chèn
  vào kho lưu trữ kiểm soát nguồn. Nhà phát triển muốn lấy
  mã mới nhất cần phải yêu cầu nó từ công cụ kiểm soát nguồn. Trong
  cơ sở dữ liệu, sự thay đổi đã tồn tại và tác động đến dữ liệu khác ngay cả khi nó không được đăng ký vào kho lưu trữ.
• Trong quá trình đăng ký tệp, công cụ kiểm soát nguồn thực hiện kiểm tra xung đột để xem liệu cùng một tệp đã được sửa đổi và đăng ký bởi nhà phát triển khác trong thời gian bạn sửa đổi bản sao cục bộ của mình. Một lần nữa không có kiểm tra cho điều này trong cơ sở dữ liệu. Nếu bạn thay đổi một quy trình từ PC cục bộ của mình và đồng thời tôi sửa đổi cùng một quy trình với mã mẫu từ PC cục bộ của mình thì chúng tôi sẽ ghi đè các thay đổi của nhau.
• Quá trình xây dựng mã được thực hiện bằng cách đưa nhãn / phiên bản mới nhất của mã vào một thư mục trống và sau đó thực hiện quá trình xây dựng - biên dịch. Đầu ra là nhị phân trong đó chúng tôi sao chép và thay thế hiện có. Chúng tôi không quan tâm những gì trước đây. Trong cơ sở dữ liệu, chúng tôi không thể tạo lại cơ sở dữ liệu vì chúng tôi cần duy trì dữ liệu! Ngoài ra, việc triển khai thực thi các tập lệnh SQL được tạo trong quá trình xây dựng.
• Khi thực thi các tập lệnh SQL (với các lệnh DDL, DCL, DML (cho nội dung tĩnh), bạn giả sử cấu trúc hiện tại của môi trường khớp với cấu trúc khi bạn tạo tập lệnh. Nếu không, thì tập lệnh của bạn có thể thất bại khi bạn đang cố thêm cột mới đã tồn tại.
• Việc coi các tập lệnh SQL là mã và tạo chúng theo cách thủ công sẽ gây ra lỗi cú pháp, lỗi phụ thuộc cơ sở dữ liệu, tập lệnh không thể sử dụng lại làm phức tạp nhiệm vụ phát triển, duy trì, kiểm tra các tập lệnh đó. Ngoài ra, các tập lệnh đó có thể chạy trên một môi trường khác với môi trường mà bạn sẽ chạy.
• Đôi khi tập lệnh trong kho điều khiển phiên bản không khớp với cấu trúc của đối tượng đã được kiểm tra và sau đó sẽ xảy ra lỗi trong sản xuất!

Có nhiều hơn nữa, nhưng tôi nghĩ rằng bạn đã có hình ảnh.

Những gì tôi tìm thấy hoạt động là như sau:

1. Sử dụng một hệ thống kiểm soát phiên bản được thi hành để thực thi các hoạt động kiểm tra / đăng ký trên các đối tượng cơ sở dữ liệu. Điều này sẽ đảm bảo kho lưu trữ kiểm soát phiên bản khớp với mã đã được đăng ký vì nó đọc siêu dữ liệu của đối tượng trong thao tác đăng ký và không phải là một bước tách biệt được thực hiện thủ công
2. Sử dụng phân tích tác động sử dụng đường cơ sở như một phần của so sánh để xác định xung đột và xác định xem có thay đổi (khi so sánh cấu trúc của đối tượng giữa kho lưu trữ kiểm soát nguồn và cơ sở dữ liệu) là thay đổi thực sự bắt nguồn từ sự phát triển hoặc thay đổi có nguồn gốc từ một đường dẫn khác và sau đó nên bỏ qua, chẳng hạn như nhánh khác hoặc cách khắc phục khẩn cấp.

Một bài báo tôi đã viết về điều này đã được xuất bản ở đây , bạn được chào đón để đọc nó.