SQL Server 2017 gặp sự cố khi sao lưu vì filepath sai


25

Tôi đã cố gắng khôi phục cơ sở dữ liệu của mình và SQL Server liên tục gặp sự cố. Tôi sẽ nhận được một tin nhắn trong SSMS nói rằng có lỗi vận chuyển mạng (kết nối bị rớt bc). Tôi đã kiểm tra nhật ký và không tìm thấy gì ngoài SQL Server đóng bất ngờ. Sau đó tôi sẽ phải đi và khởi động lại dịch vụ.

Tôi đã thu hẹp vấn đề xuống kịch bản mà GUI đang cố chạy. Vấn đề là khi nó đi sao lưu nhật ký đuôi, đường dẫn đến các tệp sao lưu bị sai. Nó nênD:\mapbenefits\...

BACKUP LOG [mapbenefits]
TO  DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT,  NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
    NOSKIP, NOREWIND, NOUNLOAD,  NORECOVERY ,  STATS = 5

Tôi có hai câu hỏi.

  1. Làm cách nào để sửa đường dẫn này? Tôi đã thử đi vào cài đặt máy chủ và đường dẫn sao lưu D:không có dấu gạch chéo. Nếu tôi thêm dấu gạch chéo, gui sẽ loại bỏ nó. Đây là SSMS v17.9.1. Tôi có thể chọn D:\mapbenefits\và nó hoạt động nhưng tôi muốnD:\DATABASE\...

  2. Đây có phải là một lỗi? Máy chủ SQL có bị sập chỉ vì một đường dẫn được gõ không chính xác? Khi tôi đã sửa đường dẫn tệp, nó không gặp vấn đề gì. Tôi có thể sinh sản bất cứ lúc nào chỉ bằng cách nhét filepath.

Nếu tôi chạy một truy vấn để kiểm tra phiên bản, tôi nhận được CU13, nhưng nếu tôi vào cài đặt, tôi thấy phiên bản 14.0.1000.169.

Có vẻ như đây là một lỗi và có thể tái tạo được nên tôi đã đăng nó lên đây: https://feedback.azure.com/forums/908035-sql-server/suggestions/36920542-inc Corr-filepath-with-backup-log-common- nguyên nhân

Câu trả lời:


25

Tôi đã có thể tái tạo điều này.

Vào năm 2016, nếu tôi đặt một đường dẫn không hợp lệ như thế, tôi nhận được thông báo này:

Không thể mở thiết bị sao lưu 'D: mapbenefits_LogBackup_2019-02-21_13-58-24.bak'. Lỗi hệ điều hành 3 (Hệ thống không thể tìm thấy đường dẫn được chỉ định.)

Vào 2017 CU 13 (14.0.3048.4), kết quả là dịch vụ bị sập. Bạn đã đề cập rằng trong hotfix mới nhất (14.0.3049.1), dịch vụ không gặp sự cố, nhưng phiên bị hủy.

Tôi cũng đã xác nhận hành vi chính xác tương tự cũng áp dụng RESTORE DATABASE- vượt qua một đường dẫn như "D: Sao lưu" (với dấu gạch chéo ngược bị thiếu) hoặc "D :: \ Sao lưu" (dấu hai chấm thêm) làm hỏng phiên bản SQL Server (cảm ơn Michael K Campbell vì đã đưa cái này lên).

Nếu tôi đặt đường dẫn "hợp lệ" không tồn tại, tôi sẽ có hành vi chính xác ("không thể tìm thấy đường dẫn được chỉ định") trong năm 2017.

Đây là một lỗi - trong cả CU 13 và bản dựng hotfix. Truyền tham số không chính xác cho BACKUPhoặc RESTOREcác lệnh không nên làm sập dịch vụ hoặc giết phiên của bạn. Bạn có thể báo cáo nó trên trang web phản hồi .

Lưu ý: phiên bản lỗi dịch vụ của lỗi này có thể được sao chép trong phiên bản xem trước công khai của SQL Server 2019 (CTP2.2 - cảm ơn Denis Rubashkin đã chỉ ra điều này)


Nhìn vào điều này trong một trình gỡ lỗi, có vẻ như mã xác thực đường dẫn đơn giản là bị hỏng. Nó kết thúc gây ra một tràn ngăn xếp bằng cách gọi đệ quy sqlmin!CheckFileStreamReservedsau khi kiểm tra bình thường (và khá rộng) trên đường dẫn được cung cấp không có ý nghĩa của nó. Tràn ngăn xếp làm giảm dịch vụ trên bản dựng 3048. Điều tương tự cũng xảy ra vào năm 3049 ngoại trừ một chuỗi vi phạm truy cập trong khi cố gắng xử lý tràn ngăn xếp thay vì phá vỡ kết nối thay vì dừng toàn bộ máy chủ.


Bản sửa lỗi cho lỗi này đã được phát hành trong SQL Server 2017 CU 15:

CỐ ĐỊNH: SQL Server 2017 gặp sự cố do lỗi tràn ngăn xếp khi bạn cố sao lưu cơ sở dữ liệu chủ vào đĩa

Vấn đề cũng được giải quyết trong SQL Server 2019 CTP 3.0.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.