Xử lý sự cố

Sửa lỗi ORA-03113 end of file on communication channel (P2)

Sửa lỗi ORA-03113 end of file on communication channel – Phần 2

bài trước chúng ta đã cùng tìm hiểu các vấn đề đầu tiên, nguyên nhân gây ra lỗi ORA-03113. Tiếp đây là phần tiếp theo , từng phần khi gặp phải lỗi ORA-03113 này

A1.5) lỗi xảy ra khi ” startup nomount”

Kiểm tra các tập tin init.ora/spfile để có thể startup database

Có thể làm lại một spfile thực sự cơ bản để có thể startup các instance

A1.6) Kiểm tra các log, trace log trên hệ điều hành để có thể cung cấp thông tin, xác minh lỗi này có thuộc do hệ điều hành hay không

A1.7) Đảm bảo còn dung lượng tại các phân vùng:

a. đường dẫn USER_DUMP_DEST và BACKGROUND_DUMP_DEST của bạn

b.AUDIT destination (Unix)

Default của đường dẫn là $ORACLE_HOME/rdbms/audit

A1.8) Chỉ xảy ra trên nền tảng Windows

Nếu tập tin sqlnet.ora của máy chủ chứa các dịch vụ xác thực không thể truy cập bởi Oracle và xảy ra lỗi ORA-03113 thì sẽ xử lý như sau

Bỏ tham số SQLNET.AUTHENTICATION_SERVICES = (NTS) trên file sqlnet.ora để Oracle không phải tìm kiếm một KDC (Kerberos Domain Controller) không tồn tại

A2) Lỗi khi mount oracle database

Kiểm tra tất cả các lỗi trong mục A1 để có thể loại bỏ các trường hợp

Nếu xảy ra lỗi khi mount database thì có thể có vấn đề với control file và datafile hoặc với các resources cần thiết để mở các file này

A2.1) Đường dẫn của controlfile được quy định trong init.ora/spfile nên có thể một trong các control file bị hỏng. Bạn có thể sửa lại spfile và xóa bỏ thử một trong các control file để xác minh được control file bị corrupt và chạy lại

Ví dụ: Shutdown abort

sửa file init.ora/spfile

startup nomount

alter database mount

Lặp lại quá trình này với mỗi thông số trong spfile là một control file khác nhau

A2.2) Có thể tạo lại controlfile nếu bạn biết tất cả các vị trí của datafile và online logs hoặc có thể khôi phục lại control file từ một bản backup controlfile có trước
( các bước này không có trong bài viết dưới đây)

A3) Lỗi khi Recover Database

Lỗi ORA-03113 xảy ra khi recover database thường liên quan đến corrupt trên database hoặc quá trình luân phiên của redo bị hỏng

A3.1) Sử dụng câu lệnh dưới đây ngay trước khi chạy câu lệnh ‘recover database’

SQL> alter session set max_dump_file_size=unlimited;

SQL> alter session set events

2> '10228 trace name context forever, level 10';

SQL> RECOVER DATABASE

Phần này để các thông tin trên redo được lưu lại trên trace file. Các thông tin cuối cùng của redo được lưu lại giúp xác định những tập tin có vấn đề

A3.2) Nếu bạn không có nhiều datafile thì có thể sử dụng cách recover từng datafile một để làm hẹp phạm vi giải quyết vấn đề

Ví dụ:

SQL> select name from v$datafile;

SQL> RECOVER DATAFILE 'full_file_name'

A4) Lỗi trong khi ALTER OPEN DATABASE

Các phân dưới đây giúp bạn cô lập vấn đề một cách nhanh chóng hơn và sử dụng mọi thông tin trace file để có thể giải quyết các vấn đề

A4.1) Di chuyển đường dẫn USER_DUMP_DEST và BACKGROUND_DUMP_DEST sang phân vùng mới có nhiều dung lượng còn trống hoặc đảm bảo dung lượng trên các phân vùng này vì các bước làm dưới đây sinh ra rất nhiều logs

A4.2) Chỉnh sửa init.ora/spfile và thêm vào các tham số sau

event="10046 trace name context forever, level 12"

event="10015 trace name context forever, level 1"

event="10228 trace name context forever, level 1"

Những thông tin này sẽ theo dõi sql và hoạt động BIND trong quá trình khởi động.

Thêm đó còn có các thông tin REDO applied, thông tin rollback transaction

Đồng hành cùng doanh nghiệp vượt qua khó khăn giai đoạn Covid-19, chúng tôi tặng bạn Voucher giảm giá 60% dịch vụ kiểm tra sức khỏe cơ sở dữ liệu toàn diện, dịch vụ Database Health Check giúp CSDL của bạn luôn khỏe mạnh!
Chi tiết xem tại đây!

Leave a Reply

avatar
  Subscribe  
Notify of