1c đã phát hiện thao tác cập nhật cấu hình cơ sở dữ liệu chưa hoàn chỉnh. Chú ý!!! Đã xảy ra lỗi khi cập nhật dữ liệu sau lần tái cấu trúc gần đây nhất. Lặp lại cập nhật? C, khôi phục cấu hình cơ sở thông tin bằng MS SQL

Hộp cát

Valera Ngày 18 tháng 9 năm 2013 lúc 03:24 chiều

1C, khôi phục cấu hình cơ sở thông tin bằng MS SQL

Máy chủ Microsoft SQL,
Quản lý cơ sở dữ liệu

Có lần tôi gặp phải một vấn đề: khi cập nhật cấu hình từ kho lưu trữ thì xảy ra lỗi và 1C bị đóng.

Hóa ra sau đó, bộ lưu trữ cấu hình đã bị phá hủy và khi cập nhật cấu hình, cấu hình cơ sở dữ liệu cũng bị xóa khỏi bộ lưu trữ. Một lỗi tương tự đã xảy ra trước đây trong quá trình cập nhật động về bảo mật thông tin.

Bởi vì Vấn đề này đã phát sinh nhiều lần và tôi quyết định chia sẻ một phương án điều trị.

Lần tiếp theo bạn khởi động trình cấu hình, một lỗi xuất hiện: “Chú ý!!! Đã xảy ra lỗi khi cập nhật dữ liệu sau lần tái cấu trúc gần đây nhất. Tôi có nên lặp lại cập nhật không? Nếu câu trả lời là có, chúng tôi nhận được thông báo: “Đã phát hiện thấy thao tác lưu cấu hình chưa hoàn tất. Để tiếp tục làm việc, bạn phải hoàn thành thao tác” sau đó ứng dụng sẽ đóng lại.

Khi phân tích vấn đề này, một số giải pháp đã được tìm ra, mỗi giải pháp có tác dụng trong những trường hợp khác nhau.

Tùy chọn 1 (nếu bạn có bản sao lưu SQL với bản sao có cấu hình giống hệt):

Một bản sao bảo mật thông tin được triển khai và yêu cầu sau được thực thi:
SỬ DỤNG ĐI XÓA TỪ .. ĐI CHÈN VÀO .. CHỌN * TỪ .. ĐI
Trong trường hợp này, bảng lưu trữ cấu hình bảo mật thông tin sẽ được nạp lại. Nên kiểm tra và sửa lỗi bảo mật thông tin sau thao tác này.

Tùy chọn 2 (nếu không có bản sao lưu):

Tùy chọn này đã được biến thành ống hút cuối cùng. Bởi vì cấu hình đang được phát triển và họ quên mất việc sao lưu một chút, dựa vào bộ nhớ.
Trong cơ sở dữ liệu, hai bản ghi sẽ bị xóa khỏi bảng “Config” theo giá trị trong cột “FileName” - dbStruFinal và commit

Truy vấn sau đây được thực hiện:
SỬ DỤNG ĐI XÓA TỪ . WHERE FileName = "dbStruFinal" ĐI XÓA TỪ . WHERE FileName = "cam kết" ĐI
Thật kỳ lạ, phần đế lại trở nên sống động.

Tags: 1C Enterprise 8.2, SQL, khôi phục cấu hình

Bài viết này không thể bình luận vì tác giả của nó chưa phải là thành viên chính thức của cộng đồng. Bạn sẽ chỉ có thể liên hệ với tác giả sau khi anh ấy nhận được

Xin chào các độc giả thân mến.

Mới đây tôi đã phải khôi phục cơ sở dữ liệu 1C Enterprise 8 sau một sự cố xảy ra trong quá trình cập nhật cấu hình. Hơn nữa, điều này đã xảy ra hai lần và các phương pháp được sử dụng trong quá trình khôi phục cũng khác nhau (bạn sẽ sớm tìm ra lý do). Trong bài viết này tôi muốn nói về các phương pháp tôi đã sử dụng.

Tất cả các phương pháp được thảo luận trong bài viết đều đề cập đến phiên bản máy chủ 1C Enterprise 8, được sử dụng bởi DBMS - MS SQL 2005.

Trường hợp số 1.

Khi cập nhật cấu hình, lỗi “Khóa xung đột” hiển thị và bộ cấu hình đã bị đóng. Khi cố gắng đăng nhập lại vào cấu hình thì xuất hiện lỗi: Chú ý!!! Đã xảy ra lỗi khi cập nhật dữ liệu sau lần tái cấu trúc gần đây nhất. Tôi có nên lặp lại cập nhật không? "Không hẳn"

Nếu câu trả lời là tích cực, thông báo sau sẽ được hiển thị “Đã phát hiện thao tác lưu cấu hình chưa hoàn chỉnh. Bạn phải hoàn thành thao tác để tiếp tục."

Tìm kiếm trên Internet đã tiết lộ phương pháp sau. Trong bàn Cấu hình dữ liệu cơ sở dữ liệu của chúng tôi cần xóa các dòng trong đó trường Tên tệp = cam kết hoặc FileName = dbStruFinal hoặc FileName=DynamivelyUpdated (cho 8.3) hoặc FileName=dynamicCommit (8.3) và cũng dọn bàn Cấu hìnhSave. Hãy để tôi giải thích những dữ liệu bảng này chịu trách nhiệm gì: Config - bảng này lưu trữ cấu hình cơ sở dữ liệu, ConfigSave - bảng này lưu trữ cấu hình làm việc, tức là. trước khi nhấn nút F7 trong bộ cấu hình.

Mở SQL Serger Management Studio và mở cửa sổ truy vấn bằng nút “ Truy vấn mới» mở một cửa sổ truy vấn.

Trong cửa sổ truy vấn, chúng tôi viết các truy vấn và thực hiện chúng:

xóa khỏi [OurBaseName].. trong đó FileName = 'commit'
xóa khỏi [OurDatabaseName].. trong đó FileName = 'dbStruFinal'
xóa khỏi [Tên cơ sở dữ liệu của chúng tôi].. trong đó Tên tệp = 'Cập nhật động' (đối với phiên bản 8.3)
xóa khỏi [OurDatabaseName].. trong đó FileName = 'dynamicCommit' (đối với phiên bản 8.3)
xóa khỏi [OurBaseName]..

Sau khi hoàn thành các yêu cầu này, trình cấu hình bắt đầu mà không gặp vấn đề gì.

Trường hợp số 2

Nguyên nhân lỗi đăng nhập vào bộ cấu hình cũng giống như trường hợp đầu tiên: xung đột khóa khi cập nhật cấu hình.

Xóa các hàng trong bảng Cấu hình và dọn bàn Cấu hìnhSave Nó đã giúp được một phần: bộ cấu hình đã mở, nhưng nó không hoạt động ở công ty biểu mẫu được quản lý.

Trong trường hợp này, tôi nghĩ đến 2 con đường phát triển:

Khôi phục từ một kho lưu trữ. Có một chữ “NHƯNG” lớn trong tùy chọn này: tình cờ là kho lưu trữ được tạo sau khi cập nhật, tức là. kho lưu trữ có lỗi.
Có một ý tưởng sử dụng cấu hình cơ sở dữ liệu phân tán nhưng không được cập nhật vì tệp để trao đổi bị lỗi.

Để giải quyết vấn đề, phương án 2 đã được chọn. Tiếp theo, tôi sẽ kể cho bạn nghe từng bước những gì tôi đã làm.

Ví dụ: mở SQL Serger Management Studio và tạo cơ sở dữ liệu tùy chỉnh Perenos. Chúng tôi tạo một bảng trong cơ sở dữ liệu này Cấu hình.Đối với những người không biết sql để truyền dữ liệu từ bảng này sang bảng khác, MS SQL có một dịch vụ tuyệt vời “ Trình hướng dẫn nhập và xuất SQL Server". Sử dụng dịch vụ này, bạn có thể dễ dàng chuyển dữ liệu từ cơ sở dữ liệu này sang cơ sở dữ liệu khác. Để bắt đầu dịch vụ này, bạn cần nhấn phím " ctrl+r" và trong hộp thoại viết lệnh " dtswizard «.
Chúng tôi chuyển khoản bằng dịch vụ dtswizard bảng dữ liệu Cấu hình cơ sở dữ liệu của chúng tôi vào một bảng Cấu hình căn cứ Perenos.
Dọn dẹp bàn Cấu hình trong cơ sở dữ liệu của chúng tôi bằng cách sử dụng một yêu cầu xóa khỏi [OurBaseName]..
Trên máy chủ nơi đặt cơ sở dữ liệu phân tán, chúng tôi khởi chạy dịch vụ dtswizard và truyền dữ liệu từ bảng Cấu hình vào cùng một bảng chỉ trong cơ sở dữ liệu của chúng tôi.

Với sự trợ giúp của những hành động như vậy, có thể khôi phục chức năng của cơ sở dữ liệu một cách nhanh chóng và với thời gian ngừng hoạt động tối thiểu.

Sự cố mà bài viết đề cập đến xảy ra khi bộ cấu hình gặp sự cố tại thời điểm cơ sở dữ liệu đang được cơ cấu lại, tức là ở một trong những giai đoạn cuối cùng của quá trình cập nhật cấu hình. Giải pháp được mô tả trong bài viết áp dụng cho phiên bản máy khách-máy chủ của nền tảng 1C: Enterprise, sử dụng MS SQL Server làm DBMS.

Các triệu chứng có thể bao gồm các cảnh báo hệ thống sau:

1) Khi cố gắng khởi động cơ sở dữ liệu ở chế độ cấu hình:

2) Khi cố gắng khởi động cơ sở dữ liệu ở chế độ doanh nghiệp:

3)Khi nhập bộ cấu hình, hệ thống cũng có thể đưa ra giải pháp sau:

Chúng ta có thể trả lời câu hỏi này bằng cách khẳng định. Và thường thì vấn đề được giải quyết theo cách này. Nhưng không phải lúc nào cũng vậy.

Hệ thống có thể phản hồi sự đồng ý của chúng tôi để tiếp tục cập nhật bằng thông báo sau:

Hoặc yêu cầu quyền truy cập độc quyền, điều này không phải lúc nào cũng thuận tiện trong các hệ thống có số lượng lớn người dùng và đôi khi đơn giản là không thể.

Trong trường hợp này, MS SQL Server sẽ giúp chúng ta. Để giải quyết vấn đề của chúng tôi, việc thực thi tuần tự các tập lệnh sau là đủ (tất nhiên, trong bối cảnh cơ sở dữ liệu có vấn đề).

1) Trước tiên, hãy tạo bản sao của bảng Config và ConfigSave (sau này, chúng có thể bị xóa).

LỰA CHỌN *

VÀO Cấu hình_copy

TỪ [Cấu hình]

LỰA CHỌN *

VÀO Cấu hìnhSave_copy

TỪ

Chính trong các bảng này, thông tin về cấu hình và tiến trình cập nhật được lưu trữ. Bảng đầu tiên lưu trữ thông tin về cấu hình cơ sở dữ liệu, bao gồm dữ liệu cập nhật mới nhất. Bảng thứ hai chứa dữ liệu từ cấu hình mới, chưa được lưu. Bằng cách phân tích nội dung của các bảng này, hệ thống sẽ nhận được dữ liệu về mức độ thành công (hoặc không thành công) của lần cập nhật gần đây nhất.

2) Xóa tất cả các mục khỏi bảng ConfigSave (lưu trữ cấu hình cuộn)

XÓA TỪ

3) Xóa ba mục khỏi bảng Cấu hình (chúng lưu trữ thông tin về quá trình cập nhật cấu hình chưa hoàn thành)

XÓA TỪ

Ở ĐÂU FileName IN ("commit" , "dbStruFinal" , "dynamicCommit" )

Các bản ghi về bản cập nhật mới nhất của chúng tôi sẽ xuất hiện trong bảng Cấu hình, bảng này có thể dễ dàng kiểm tra bằng cách “chọn” thông thường.

Thời tiền sử.

Hai ngày trước, chúng tôi đã thực hiện chuyển đổi từ 8.1 sang 8.2 - chúng tôi đã thay đổi cấu hình của UPP 1.2... thành 1.3.22.1. Theo đó, có rất nhiều điểm khác biệt so với cấu hình tiêu chuẩn được tung ra dẫn đến hàng loạt lỗi. Trong hai ngày không nghỉ qua đêm, chúng tôi thay đổi cấu hình không ngừng. Bộ cấu hình được lưu 15 lần mỗi giờ. Người ta dự đoán rằng khi lưu, cấu hình có thể bị lỗi, đó chính xác là những gì đã xảy ra. Những vấn đề như vậy, trong conf 8.1, luôn được giải quyết bằng cách thoát ra của những người dùng vẫn đang làm việc trong cơ sở dữ liệu nhưng không thể đăng nhập lại và có quyền truy cập độc quyền. Trong cấu hình 8.2 mới của chúng tôi, cơ sở dữ liệu đã thông báo cho chúng tôi “Tôi mệt. Tôi sắp rời đi”), nhìn chung vấn đề đã được mô tả trong thông báo.

Việc gì đã làm đúng và sai. Và lời khuyên nên làm gì đầu tiên.

Trước hết, trong tình trạng hỗn loạn, chúng ta bắt đầu tìm cách giải quyết vấn đề nảy sinh trên Internet. Hiện tại, Google đưa ra đúng 3 bài viết về nội dung lỗi xảy ra. Tôi sẽ liệt kê chúng.

Nhìn chung, trong cả ba bài viết, câu trả lời cho giải pháp cho vấn đề hiện tại đều giống nhau - “Khôi phục cơ sở dữ liệu từ bản sao lưu”.

Không cần phải nói về tầm quan trọng của việc sao lưu, tính thường xuyên của chúng, v.v. Tôi nghĩ rằng đối với chúng tôi thì đây là một cảnh báo tốt, mặc dù chúng tôi đã sao lưu cơ sở dữ liệu sau khi nó được lưu ở cấu hình 1.3, nhưng rất ít người theo dõi tính thường xuyên của chúng và thực tế là chúng đã hoàn thành (và ổ cứng không được dọn dẹp) , vân vân.). Theo đó, hãy tha thứ cho “Sự hiển nhiên của thuyền trưởng”, nhưng nếu bạn có một bản sao lưu mới, điều đầu tiên cần làm là khôi phục cơ sở dữ liệu từ đó, đừng lãng phí thời gian quý báu, vì vậy ban quản lý sẽ không cảm ơn bạn vì thời gian ngừng hoạt động. Tuy nhiên, bạn có thể cố gắng hồi sinh căn cứ “đã sụp đổ”, điều này đã được thực hiện nhờ sự kiên trì của tôi. Tôi lưu ý rằng một lập trình viên khác cũng đã cố gắng bằng cách nào đó khôi phục cơ sở dữ liệu bằng phương pháp 1C, nhưng không thành công. Tôi không biết anh ấy đã làm gì, nhưng tôi đã thấy những nỗ lực khởi chạy 1C ở chế độ lệnh ngay lập tức bằng việc khởi chạy Kiểm tra và sửa lỗi bảo mật thông tin, thực tế không khởi chạy bất cứ thứ gì.

Tôi tập trung sự chú ý của mình vào SQL. Tôi đã quen với một chút kinh nghiệm trong việc định cấu hình và quản trị cơ sở dữ liệu cũng như một bộ lệnh SQL điển hình, nhưng phương pháp được nêu dưới đây không yêu cầu bất kỳ kiến thức và kỹ năng sâu nào khi làm việc với SQL. Tôi chỉ đơn giản kết nối logic - nếu cơ sở dữ liệu “rơi” trong khi lưu cấu hình, chúng tôi kết luận rằng cấu trúc của một bảng trong SQL có thể đã bị sập (mặc dù trước đó tôi không biết rằng cấu hình trong phiên bản 8 nằm trong một bảng tiếp theo) và bảng này trong đó nó được lưu trữ cấu hình cơ sở dữ liệu. cụ thể là bảng dbo.config. Sau đó, tôi phát hiện ra cách sử dụng phương pháp “chọn riêng” và một lần nữa, logic, bởi vì điều duy nhất tôi tìm thấy là sự phát triển địa phương, điều này không giúp ích gì cho tôi nhưng khá hữu ích cho tương lai, cụ thể là Cảm ơn tác giả từ tài khoản của đồng nghiệp của tôi, với sự giúp đỡ của người mà tôi đã tải xuống. Vì vậy, tôi chuyển sang điều quan trọng nhất - cố gắng (!) để khôi phục cơ sở dữ liệu vì thật không may, tôi không thể đưa ra bất kỳ đảm bảo nào cho bạn và có một số cài đặt trước mà bạn có thể không có hoặc, như họ nói, đây không phải là của bạn trường hợp...

Yêu cầu và việc khôi phục cơ sở dữ liệu.

(Chú ý. Hãy nhớ xem chú thích cuối trang bên dưới nếu bạn muốn cố gắng tự phục hồi cấu hình. Hôm nay (18/04/2012) qua thử nghiệm, tôi đã thành công vì cảm thấy tiếc cho công việc kéo dài một tuần đã được thực hiện trên đó. Do đó, có thể khôi phục cơ sở dữ liệu, không để lại cấu hình cũ mà không có bất kỳ bản sao nào)

Dữ liệu ban đầu - Cơ sở dữ liệu SQL 1C 8.2, cấu hình UPP 1.3.22.1 (Tôi tin rằng phương pháp được mô tả phù hợp với mọi cơ sở dữ liệu tiêu chuẩn 8.2). Máy chủ SQL 2005. Lỗi được mô tả trong thông báo và lỗi xảy ra khi lưu cấu hình! Yêu cầu quan trọng và bắt buộc nhất!!! Một bản sao của cơ sở dữ liệu SQL có CẤU HÌNH CÙNG(!) Chúng tôi đã định cấu hình tự động trao đổi với cơ sở dữ liệu khác và cấu hình của chúng giống nhau. Ngoài ra, vì chúng tôi là ba lập trình viên 1C nên mỗi người chúng tôi đều có một tệp conf được tải lên và tương đối gần đây. Trên thực tế, bất kỳ cơ sở dữ liệu nào cũng được, bất kể dữ liệu nào, điều chính là cấu hình trong đó phù hợp với cấu trúc siêu dữ liệu của cơ sở dữ liệu. Tôi muốn lưu ý thực tế là cấu hình thậm chí còn hơi khác so với cấu hình mà phần đế bị hỏng. Theo tôi, yêu cầu cơ bản nhất là sự khác biệt về cấu hình không ảnh hưởng đến siêu dữ liệu. Đừng quên thực tế là nếu cấu hình khác thì cuối cùng bạn sẽ nhận được một cơ sở dữ liệu đang hoạt động nhưng có cấu hình từ bản sao của bạn.

Bản thân quá trình khôi phục sẽ không làm bạn mất nhiều thời gian - nghĩa đen là vài phút, nhưng tôi thực sự khuyên bạn nên tạo bản sao lưu ngay cả cơ sở dữ liệu “bị hỏng” trước, nhưng có thể mất thời gian. Ví dụ: bạn sẽ có cơ hội khôi phục cơ sở dữ liệu bằng cách quay lại từ tệp nhật ký (không may là tệp này đã bị “cấm” trong quá trình khôi phục hỗn loạn) hoặc một số phương pháp khác. Vì vậy, hãy để tôi nhắc bạn rằng ở đâu đó phải có cơ sở dữ liệu SQL, bất kể dữ liệu nào, nhưng có cùng cấu hình. Nếu cấu hình của bạn là cấu hình tiêu chuẩn "chưa được xử lý" (có nghĩa là sự cố này đã phát sinh trong quá trình triển khai cấu hình tiêu chuẩn mới), bạn có thể tạo cơ sở dữ liệu trống mới và điền vào đó cấu hình tiêu chuẩn mà bạn có trước đó. Nếu cấu hình bạn tìm thấy không quá mới, hãy suy nghĩ và đưa ra quyết định; có lẽ sự khác biệt với bản sao của bộ cấu hình mà bạn sẽ buộc phải lặp lại trong cơ sở dữ liệu của mình sẽ tốn nhiều thời gian và tài nguyên hơn là mất thông tin. chính cơ sở dữ liệu 1C. Một loại dao hai lưỡi) Vậy...

1. Tạo bản sao lưu cơ sở dữ liệu bị lỗi bằng SQL.

2. Chúng tôi xóa bảng dbo.config của cơ sở dữ liệu, bảng chứa conf bị hỏng. Điều này có thể được thực hiện từ SQL Profiler, chẳng hạn bằng cách chạy lệnh trong đó:

Xóa từ .

trong đó Base2009 là tên của căn cứ bị rơi.

Lưu ý: Tôi đã đọc một số thông tin chưa được xác minh ở đâu đó trên mạng và đôi khi nó giúp xóa bảng dbo.ConfigSave, bảng này được cho là có chứa conf cuộn lên. Trong cơ sở dữ liệu của chúng tôi, nó trống rỗng, vì vậy rõ ràng là tôi đã không dọn sạch cái bàn trống. Có lẽ - bằng cách nào đó bạn có thể đánh lừa và khôi phục cơ sở dữ liệu 1C bằng bảng này, nhưng nếu không biết cơ chế hoạt động của 1C với bảng này, tôi sẽ không nói bất cứ điều gì về hành động liên quan đến nó.

3. Sao chép bảng từ cơ sở dữ liệu có toàn bộ cấu hình vào cơ sở dữ liệu bị hỏng của chúng tôi. Trong trường hợp của tôi, cả hai cơ sở dữ liệu đều nằm trên cùng một máy chủ, vì vậy lệnh sao chép trong SQL-Profiler trông như thế này.

chèn vào .. chọn * từ ..

trong đó base2009 là tên của cơ sở dữ liệu bị lỗi, BaseCopy là tên của cơ sở dữ liệu có bản sao của bộ cấu hình

4. Chúng tôi khởi chạy 1C và nếu thành công, chúng tôi sẽ nhảy vọt, như tôi đã làm, với niềm vui rằng chúng tôi đã khôi phục được cơ sở dữ liệu mà không bị mất thông tin.

5. (Thuyền trưởng rõ ràng) chúng tôi kiểm tra, gỡ lỗi và giám sát hệ thống tạo bản sao lưu cơ sở dữ liệu và thực hiện một cách tiếp cận rất có trách nhiệm đối với quá trình cập nhật cấu hình (chúng tôi thực hiện việc này không qua mạng mà tốt nhất là trên máy chủ, nếu có thể, hãy tạo một bản sao lưu sao lưu trước). Đặc biệt nếu phiên bản 1C của bạn đã trở thành 8.2. Theo như tôi hiểu từ các bài báo trên Internet và hai ngày đầu tiên làm việc với nó, nó nhạy cảm và thất thường hơn so với 8.1 vốn không có vấn đề gì như vậy.

5a. Nếu cấu hình của cơ sở dữ liệu mà bạn sẽ sao chép bảng conf vẫn khác (không có sự khác biệt về siêu dữ liệu mà tôi đã đề cập) và ở đâu đó có tệp cf tương đối mới của bạn với conf chưa được tải - hãy cuộn nó vào cơ sở đã được khôi phục . Nếu không, bạn sẽ phải lặp lại tất cả những khác biệt có trong bản sao của bộ cấu hình. Vì vậy, hãy suy nghĩ lại và phân tích điều gì quan trọng hơn: công việc của bạn trong việc thay đổi cấu hình (và bạn sẽ dành bao nhiêu thời gian cho việc đó) hoặc công việc của người dùng cơ sở dữ liệu cho đến lần sao lưu cuối cùng. Trong trường hợp của tôi, đó là công việc của 2 lập trình viên trong 3 giờ so với công việc của khoảng 100 người dùng trong 1,5 ngày, vì vậy sự lựa chọn là hiển nhiên.

ZY Tôi nhắc lại cho bạn nhé? rằng chức năng khôi phục này là một cách không có giấy tờ để khôi phục cơ sở dữ liệu bởi cừu 1C (trong trường hợp cụ thể xảy ra sự cố sập cơ sở dữ liệu trong khi lưu conf) và mọi thứ bạn làm đều được thực hiện với nguy cơ và rủi ro của riêng bạn, nhưng cụ thể là trong trường hợp của tôi thì có là những cách khác để khôi phục cơ sở dữ liệu với mức tối thiểu. Không bị mất thông tin hiện có (tệp nhật ký bị mất và bản sao lưu gần đây nhất thể hiện việc mất 1,5 ngày làm việc đối với khoảng 100 người dùng), vì vậy, như người ta nói, các cầu nối đã bị mất bị đốt cháy)

Z.Y.Y. Đây là ấn phẩm đầu tiên của tôi ở đây bởi vì... Tôi là một kẻ hèn nhát trên các diễn đàn 1C khác, nhưng tôi thấy tài nguyên này là một trong những tài nguyên hữu ích nhất về mặt phát triển và ấn phẩm được đăng, vì vậy đừng đánh giá khắt khe nhiều IF trong ấn phẩm này). Tôi sẽ rất vui nếu tôi thực sự giúp được ai đó khôi phục lại căn cứ bị phá hủy, bởi vì điều duy nhất tồi tệ hơn thế là chiến tranh hạt nhân)

Z.Y.Y.Y. 3 tuần sau, sự cố lại lặp lại) Lần này, giải pháp chỉ mất vài giây (nếu bạn không tính đến thời gian tạo bản sao lưu) và thậm chí người dùng cũng không bị đuổi ra ngoài .

_____________________________________________________________________________________________________________

Hôm nay có một đồng nghiệp chạy tới. Vấn đề tương tự. Chỉ có cơ sở dữ liệu là cơ sở dữ liệu thử nghiệm chứ không phải cơ sở dữ liệu đang hoạt động và bản thân cơ sở dữ liệu cũng chỉ có vậy - nhưng bộ cấu hình rất quan trọng đối với anh ta. Anh ấy đã dành một tuần để làm việc với nó mà không một lần tải tệp lên cf và không đưa ra các thay đổi đối với cơ sở dữ liệu đang hoạt động. Chà, tại sao không đào sâu hơn với cái bàn?! Lần này thậm chí còn dễ dàng hơn. Tôi mở SQL Management Studio. Tôi tạo một truy vấn trên bảng cho các trường có ngày sửa đổi hiện tại và thời gian cơ sở dữ liệu gặp sự cố - kết quả cho ra 2 bản ghi. Đầu tiên là Field FileName = "commit" Chà, làm hỏng mục nhập này - và mọi thứ đều ổn với tôi! Bộ cấu hình đã hoạt động và cơ sở dữ liệu đang hoạt động trở lại. Những gì cần phải được thực hiện?!

Vì vậy, trong cửa sổ SQL Management Studio đang mở, chúng tôi tìm kiếm cơ sở dữ liệu của mình - mở Bảng, tìm bảng có conf ở cuối danh sách dbo.config trên bàn - nút bên phải - Mở bàn. Tiếp theo, trong cửa sổ bên phải, đi xuống bảng theo thứ tự bảng chữ cái đến trường có FileName = "commit". Chúng tôi đi đến mục này - nút chuột phải - Xóa bỏ. Nói chung, chúng tôi xóa mục nhập bằng tệp nhị phân. Tiếp theo, chúng tôi cố gắng nhập conf. Lỗi tương tự xuất hiện đầu tiên. Có lẽ nó đã không thành công? ĐƯỢC RỒI. Và sau đó, trước khi đưa ra thông báo thứ hai về việc không thể lưu, như trước đây, máy tính bắt đầu suy nghĩ. Sau 30 giây - ôi PHÉP LẠI! Trình cấu hình đã mở. Chúng tôi cố gắng lưu cấu hình (sau khi lưu tệp cf). Bộ cấu hình đã được lưu. Như vậy, sói được cho ăn và đàn cừu được an toàn. Tôi không chắc chắn về chức năng đầy đủ của cơ sở dữ liệu sau khi lạm dụng như vậy - vì vậy tôi khuyên bạn nên cơ cấu lại và tính toán lại kết quả vào buổi tối (tất nhiên là sau khi tạo một bản lưu trữ). Chúc bạn may mắn hồi phục và có cảm xúc tích cực)

Hộp cát

người Sắt Ngày 18 tháng 9 năm 2013 lúc 03:24 chiều