Tôi đang trong quá trình thay thế phần cứng cho cụm RAC 3 nút hiện có. Hệ thống này cũng là cơ sở dữ liệu chính cho cơ sở dữ liệu dự phòng RAC 2 nút. Để thay thế phần cứng, kế hoạch của tôi là tạm thời mở rộng cụm thành cấu hình 6 nút, 3 máy chủ cũ và 3 máy chủ mới. Sau khi tôi có các phiên bản đang chạy trên phần cứng mới và các ứng dụng của tôi kết nối với các phiên bản mới, tôi sẽ gỡ bỏ các phiên bản cũ và gỡ bỏ các máy chủ cũ, quay lại cấu hình 3 nút.
Sau khi mở rộng cụm cho tất cả sáu nút, cuối tuần trước, tôi đã bắt đầu các phiên bản mới trên các nút mới. Để làm cho cuộc sống của tôi dễ dàng hơn, tôi chỉ cần sử dụng DBCA cho công việc này. Sau khi kích hoạt DBCA, tôi chọn làm việc trên cơ sở dữ liệu RAC, sau đó chọn Quản lý phiên bản và sau đó Thêm phiên bản mới. Dạo qua trình hướng dẫn, tôi đã để DBCA lo tất cả các chi tiết cho tôi. Nghe có vẻ đơn giản.
Sáng nay, tôi nhận được báo cáo độ trễ lưu trữ thông thường của mình. Nó trông tương tự như sau:
INSTANCE_NAME APPLICY_LAG CURR_TIME
--------------------------------- ----------- --------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Tôi gửi thư này đến Hộp thư đến của mình hai lần một ngày. Việc xem nhanh giúp tôi xác định xem chế độ chờ của mình có đang nhận và áp dụng các giao dịch từ cơ sở chính hay không. Tôi đã đặt tất cả cơ sở dữ liệu ở chế độ chờ của mình thành độ trễ áp dụng bốn giờ. Và công việc chính của tôi có ARCHIVE_LAG_TARGET được đặt thành một giờ. Điều này có nghĩa là thời gian hoãn nộp đơn sẽ ít nhất là 4 giờ nhưng không quá 5 giờ. Như chúng ta có thể thấy ở trên, chúng ta có hai cơ sở dữ liệu ở chế độ chờ đã vượt quá độ trễ áp dụng tối đa 5 giờ. Ở trên, tôi có chế độ chờ với độ trễ áp dụng là 1 ngày 21 giờ! Vì vậy, tôi ngay lập tức biết có điều gì đó không ổn. Và một nhà khoa học tên lửa không cần biết rằng việc thêm phiên bản mới vào phiên bản chính có thể góp phần gây ra vấn đề.
Như tôi đã nói ở phần đầu của bài viết này, tôi có một hệ thống dự phòng RAC 2 nút. Một trường hợp là “trường hợp áp dụng” và trường hợp khác nằm ở đó tương đối nhàn rỗi. Trong nhật ký cảnh báo phiên bản áp dụng của tôi, tôi thấy các thông báo lỗi sau:
Thứ bảy, ngày 01 tháng 12 năm 2012, 14:25:40 năm 2012
Tệp đã tạo khôi phục /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Đã thêm thành công datafile 342 vào khôi phục phương tiện
Datafile # 342:'/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
Không có đích OMF nào được chỉ định, không thể tạo nhật ký
Lỗi với nhật ký /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0:Khôi phục phương tiện nền đã kết thúc do lỗi 1264
Lỗi trong tệp /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264:Không thể tạo tên tệp logfile
Quá trình khôi phục bị gián đoạn!
Thứ bảy, ngày 01 tháng 12 năm 2012, 14:25:51 năm 2012
Đã khôi phục các tệp dữ liệu về trạng thái nhất quán tại thay đổi 192271576009
Thứ bảy, ngày 01 tháng 12 năm 2012, 14:25:51 năm 2012
MRP0:Tắt quá trình Khôi phục phương tiện nền (orcs2)
Vì tôi đã đặt cơ sở dữ liệu dự phòng thành STANDBY_FILE_MANAGEMENT =AUTO, phần đầu tiên của thông báo có ý nghĩa. Khi bạn thêm một phiên bản mới vào cơ sở dữ liệu RAC, bạn phải cung cấp Vùng bảng hoàn tác chỉ cho phiên bản đó và bạn cũng phải cung cấp các nhóm nhật ký làm lại trực tuyến dành riêng cho chuỗi của phiên bản đó. DBCA đã đặc biệt hỏi tôi các câu hỏi liên quan đến cấu trúc tệp hoàn tác và làm lại. Trong nội dung nhật ký cảnh báo ở trên, chúng ta có thể thấy rằng tệp dữ liệu 342 ở chế độ chờ đã thêm thành công tệp dữ liệu 342, đó là không gian bảng Hoàn tác của tôi. Nhưng chế độ chờ không thể thêm nhật ký làm lại trực tuyến. Nếu bạn muốn chế độ chờ có thể tự động thêm nhật ký làm lại trực tuyến, bạn cần chỉ định thông số OMF, điều này tôi không muốn làm. Vì việc bổ sung tệp nhật ký làm lại trực tuyến dẫn đến lỗi, quá trình khôi phục phương tiện ở chế độ chờ đã dừng lại. Chế độ chờ vẫn đang nhận nhật ký.
Tôi không tìm thấy nhiều thông tin trên Metalink hoặc bằng cách thực hiện tìm kiếm trên Google về cách giải quyết vấn đề này, nhưng đây là các bước tôi đã thực hiện để khôi phục phương tiện và chạy. Trên cơ sở dữ liệu dự phòng (tôi đã làm điều này trên phiên bản áp dụng nhưng nó sẽ khả thi trên bất kỳ phiên bản nào trong cơ sở dữ liệu dự phòng RAC):
1. thay đổi cơ sở dữ liệu khôi phục cơ sở dữ liệu dự phòng được quản lý hủy bỏ;
thay đổi cơ sở dữ liệu khôi phục cơ sở dữ liệu dự phòng được quản lý hủy bỏ
*
LỖI ở dòng 1:
ORA-16136:Phục hồi ở chế độ chờ được quản lý không hoạt động
Đây không phải là một cú sốc vì chúng tôi biết rằng Managed Recovery đã bị hủy bỏ. Nhưng để hoàn thiện, tôi đã bao gồm bước này. Nếu bạn phải thêm nhật ký làm lại vào chế độ chờ hiện đang áp dụng giao dịch, thì bạn sẽ cần bước này.
2. thay đổi hệ thống set standby_file_management ='MANUAL' scope =memory;
Hệ thống đã được thay đổi.
3. thay đổi cơ sở dữ liệu thêm chuỗi logfile 4 nhóm 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Cơ sở dữ liệu đã thay đổi.
Trên đây là chính xác những gì đã được chạy trên chính. Cần thêm nhật ký làm lại ở chế độ chờ chính xác như đã thực hiện trên chính. Lặp lại cho từng nhóm nhật ký làm lại được thêm vào nhóm chính. Vì tôi đã thêm 3 phiên bản vào cơ sở dữ liệu RAC chính của mình, tôi phải thêm ba chuỗi ở đây.
4. thay đổi hệ thống set standby_file_management ='AUTO' scope =memory;
Hệ thống đã được thay đổi.
Cơ sở dữ liệu đã thay đổi.
Bắt đầu khôi phục có quản lý. Hiện tại, tất cả đều tốt và chúng tôi có thể xác minh trong nhật ký cảnh báo của phiên bản ứng dụng:
thay đổi cơ sở dữ liệu khôi phục cơ sở dữ liệu dự phòng được quản lý ngắt kết nối khỏi phiên
Cố gắng bắt đầu quy trình Khôi phục chế độ chờ được quản lý trong nền (orcs2)
Thứ Hai, 03 Tháng 12, 13:32:38 2012
MRP0 bắt đầu bằng pid =47, OS id =13232
MRP0:Quá trình khôi phục chế độ chờ được quản lý trong nền đã bắt đầu (orcs2)
đã bắt đầu quy trình ghi nhật ký
Thứ Hai, 03 Tháng 12 13:32:44 2012
Khôi phục chế độ chờ được quản lý không sử dụng Áp dụng thời gian thực
Thứ Hai, 03 Tháng 12 13:32:49 2012
Phục hồi phương tiện song song bắt đầu với 4 nô lệ
Đang đợi tất cả các ORL không phải hiện tại được lưu trữ ...
Tất cả các ORL không hiện hành đã được lưu trữ.
Thứ Hai, 03 Tháng 12 13:32:49 2012
Đã hoàn thành:thay đổi cơ sở dữ liệu khôi phục cơ sở dữ liệu dự phòng được quản lý ngắt kết nối khỏi phiên
Thứ Hai, 03 Tháng 12, 13:32:50 2012
Nhật ký khôi phục phương tiện /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Nhật ký khôi phục phương tiện /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Nhật ký khôi phục phương tiện /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Nhật ký khôi phục phương tiện /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Chúng tôi cũng có thể xác minh rằng thời gian hoãn nộp đơn đang ngắn lại. Trong chế độ chờ, hãy phát hành như sau:
chọn i.instance_name, d.value làm apply_lag,
to_char (sysdate, 'YYYY-MM-DD HH24:MI:SS') as curr_time
từ v $ instance i, v $ dataguard_stats d
nơi d.name ='áp dụng độ trễ';
Để biết thông tin cơ bản về cách quản lý nhật ký làm lại trực tuyến cho cơ sở dữ liệu ở chế độ chờ vật lý của bạn, hãy xem Metalink ghi chú 740675.1 Nhật ký làm lại trực tuyến ở chế độ chờ.
