Là người từng tham gia vào các dự án triển khai lớn cho hàng
không và ngân hàng, tôi có được những kinh nghiệm sâu về hệ thống CSDL qua
những lần trắng đêm phục hồi, sửa lỗi các các hệ thống CSDL của các ngân hàng,
DBA đã trở thành một nghề của tôi từ đó…
Tôi không có nhiều kinh nghiệm về việc trình bày và chỉ xin
đưa ra các tình huống, các sự cố mà CSDL đã gặp phải trong nhưng năm tháng làm
DBA của tôi.
Bài đầu tiên tôi xin giới thiếu với các bạn là: “Khôi phục CSDL khi mất UNDO TABLESPACE”
1. Tình huống như sau
1. Tình huống như sau
Khi bạn khởi đông toàn bộ hệ thống CSDL. DB thông báo:
Database not OPEN do không tìm thấy UNDO TABLESPACE.
Các trường hợp có thể xảy ra trong tình huống này là:
- Vùng đĩa chứa UNDO TABLESPACE bị hỏng hoàn toàn. Nếu bạn dùng ASM thì có thể vùng diskgroup chứa UNDO TABLESPACE bị hỏng hoặc bị drop.
- UNDO TABLESPACE đã bị xóa trên vùng đĩa của máy chủ CSDL
- Giải pháp.
- Trước hết vào lại CSDL query xem CSDL đang dùng UNDO TABLESPACE nào
Sqlplus / as sysdba
Startup mount
Show parameter
UNDO_TABLESPACE
------------------------------------
----------- ------------------------------
- Query thông tin xem UNDOTBS03 của DB có bao nhiêu datafile thuộc về nó: Chú ý trong trường hợp DB mount, chúng ta chỉ có thể query thông tin từ các view đọc được từ controlfile (nghĩa là chỉ lấy được thông tin từ các view tĩnh)
select t.name tablespace ,
d.name from v$datafile d, v$tablespace t
where D.TS# =T.TS#
and T.NAME LIKE '';
------------------------------
----------------------------------------
- Tiến hành câu lệnh thanh đổi thông số UNDO_MANAGEMENT thành MANUAL;
Alter system set
UNDO_MANAGEMENT=manual scope=spfile;
Shutdown immediate
Startup mount.
- Dùng các câu lệnh sau đây để tiến hành drop offlines các file thuộc UNDO
Alter database datafile
‘+PGUNDO1/pgdb/undotbs033.dbf’ offline drop;
Alter database datafile
‘+PGUNDO1/pgdb/undotbs032.dbf’ offline drop;
Alter database datafile
‘+PGUNDO1/pgdb/undotbs031.dbf’ offline drop;
Alter database datafile
‘+PGUNDO1/pgdb/undotbs034.dbf’ offline drop;
- OPEN CSDL:
Alter databse open;
- Tạo lại UNDOTABLE:
Create undo tablespace
UNDOTBS2 datafile ‘+PGUNDO1/pgdb/undotbs021.dbf’ SIZE 1024M;
alter system set
undo_tablespace=undotbs2 scope=spfile sid='spcms';
alter system set
undo_management = auto scope=spfile;
shutdown immediate
startup
- Hệ thống sẽ hoạt động trở lại bình thường sau khi thực hiện các bước trên
- Kết luận: Trong quá trình hoạt động của CSDL, các lỗi xảy ra là không thể tránh khỏi, người DBA cần chủ động để xử lý các sự cố này chứ đừng cầu mong hệ thống CSDL mình quản lý không có vấn đề gì trong suốt quá trình hoạt động.
Tình huống xảy ra
Khi bạn tiến hành khởi tạo lại DB, hệ thống hoạt động bình
thường nhưng có một vài hiện tượng bất thường xảy ra như sau:
- Trên hệ thống primary database không có nhiều biểu hiện bất thường trong thời gian đầu. Có thể xuất hiện một vài thông tin corrupt của SYS nhưng biểu hiện không rõ ràng lắm. Nếu hiện tượng dump này đẩy thông tin vào trace thì cần truy cập file trace và xem chi tiết thông tin này.
- Trên Dataguard sẽ có biểu hiện rõ nhất là sự cố hệ thống dataguard không apply được các archivelog tiếp theo mặc dù archivelog truyền sang đầy đủ. Xem alert.log sẽ cho ra được thông tin là archivelog bị corupts và dừng apply từ số SCN đó.
- Tùy theo hoạt động của CSDL mà lỗi này sẽ gây ra crash trên primary database nhanh hay chậm, cũng có thể kéo dài vài tiếng nếu không phát hiện kịp thời thì hệ thống sẽ down và việc khắc phục càng trở lên khó khăn hơn.
- Khi hệ thống down, bạn tiến hành khởi động lại có thể DB sẽ OPEN được nhưng chỉ kéo dài trong thời gian tương đối ngắn. Sau đó hệ thống báo dump và instance terminated.
Nguyên
nhân
- Nguyên nhân chính ở đây là do UNDO TABLESPACE bị corrupts và dẫn đến việc sinh archivelog trên hệ thống chính này cũng bị corrupts theo.
- Khi truyền sang dataguard hệ thống sẽ không thể apply được vì nó sẽ kiểm tra việc nhất quán của dữ liệu thông qua log truyền sang
- Để xem chi tiết nguyên nhân dẫn đến lỗi này, DBA mở file trace của sự cố dump chỉ dẫn trong alert.log để đọc thông tin chi tiết.
Giải
pháp
Muốn có được giải pháp sớm cho sự cố này, hệ thống cần được
cảnh báo sớm cho các tình huống xấu trước khi xảy ra hoặc ít nhất là DBA phải
nhận được cảnh báo nguy cơ trước khi khách hàng gọi điện phản ánh.
1
Giải pháp cho trường hợp DB đang còn hoạt động
Tối ưu cho sự cố này là tận dụng lúc database còn đang hoạt
động(hệ thống đã phát sinh lỗi nhưng chưa dẫn đến crash DB) là tạo lại UNDO
TABLESPACE và switch sang UNDO mới này.
Các bước thực hiện:
1.1
Query thông tin rollback segment có nguy cơ corrupt
select segment_name, status,
tablespace_name from dba_rollback_segs
where status='NEEDS
RECOVERY';
SEGMENT_NAME STATUS TABLESPACE_NAME
—————————— —————- —————–
_SYSSMU11$ NEEDS RECOVERY UNDOTBS2
_SYSSMU12$ NEEDS RECOVERY UNDOTBS2
_SYSSMU13$ NEEDS RECOVERY UNDOTBS2
_SYSSMU14$ NEEDS RECOVERY UNDOTBS2
_SYSSMU15$ NEEDS RECOVERY UNDOTBS2
_SYSSMU16$ NEEDS RECOVERY UNDOTBS2
_SYSSMU17$ NEEDS RECOVERY UNDOTBS2
_SYSSMU18$ NEEDS RECOVERY UNDOTBS2
_SYSSMU19$ NEEDS RECOVERY UNDOTBS2
_SYSSMU20$ NEEDS RECOVERY UNDOTBS2
1.2
Add các rollback_segment này vào init file
Sqlplus / as sysdba
- Create pfile=’$ORACLE_HOME/dbs/pfile.ora’ from spfile;
- Edit pfile.ora và add thông số sau đây vào:
_offline_rollback_segments
=('_SYSSMU11$','_SYSSMU12$','_SYSSMU13$','_SYSSMU14$','_SYSSMU15$','_SYSSMU16
$','_SYSSMU17$','_SYSSMU18$','_SYSSMU19$','_SYSSMU20$')
Đảm bảo rằng các thông số được sửa như dưới đây
#undo_management=AUTO à or đặt undo_management=manual
undo_tablespace=UNDOTBS1 # Yêu cầu DB sử dụng UNDO TABLESPACE
là UNDOTBS1.
- Shutdown database
- Startup the database
1.3
Drop the UNDO tablespace that is corrupt.
SQL> drop tablespace UNDOTS2 including contents and
datafiles ;
Tablespace dropped.
1.4
Recreate the tablespace.
create undo tablespace “UNDOTS1″ datafile
‘+SYSTEM/undots01a.dbf’ size 10240M AUTOEXTEND ON;
1.5
shutdown db and restart the db
- Shutdown database
- Xóa bỏ dòng _offline_rollback_segments
- Chuyển undo_management=AUTO
- undo_tablespace=UNDOTBS1
- Startup database với spfile tạo từ pfile đã sửa đổi
2
Giải pháp cho trường hợp DB crash
Trường hợp khi sự cố này dẫn đến việc DB crash hẳn và không
thể OPEN được nữa thì không thể áp dụng được giải pháp trên.
Giải pháp cho trường hợp này cần áp dụng cách lấy thông tin
trong trace file
Các bước thực hiện:
2.1
Shutdown database
- Nếu là RAC thì shutdown all nodes.
- STạo pfile để sửa các thông số cần thiết
2.2
Sửa pfile và thêm vào thông số sau:
cluster_database=false
# Lấy thông tin corrupt của UNDO
*.event = “10015 trace name context forever, level 10″
comment các thông số sau đây:
#*.undo_management=’MANUAL’
#*.undo_retention=51752
#DB02.undo_tablespace=’UNDOTS2′
2.3
Startup DB trên 1 node để lấy thông tin trace file
Đây là đoạn thông tin trong Alert_SID.log khi DB startup.
SMON: about to recover undo
segment 16
SMON: mark undo segment 16 as
needs recovery
SMON: about to recover undo
segment 17
SMON: mark undo segment 17 as
needs recovery
SMON: about to recover undo
segment 18
SMON: mark undo segment 18 as
needs recovery
Tue Nov 20 22:20:11 2007
Errors in file
/opt/oracle/admin/sdw/udump/sdw1_ora_21678.trc:
ORA-00604: error occurred at
recursive SQL level 1
ORA-00376: file 26 cannot be
read at this time
ORA-01110: data file 26:
‘/oracle/data01/sdw/undots01a.dbf’
Tue Nov 20 22:20:11 2007
Error 604 happened during db
open, shutting down database
USER: terminating instance due to error 604
Instance terminated by USER, pid = 21678
2.4
Lấy thông tin từ trace file
Dùng câu lệnh sau thực hiện hiện trên Linux:
egrep Recovering
/opt/oracle/admin/sdw/udump/sdw1_ora_21678.trc
----------------------------------------
Recovering rollback segment _SYSSMU1$
Recovering rollback segment _SYSSMU2$
Recovering rollback segment _SYSSMU11$
Recovering rollback segment _SYSSMU12$
Recovering rollback segment _SYSSMU13$
Recovering rollback segment _SYSSMU14$
Recovering rollback segment _SYSSMU15$
Recovering rollback segment _SYSSMU16$
Recovering rollback segment _SYSSMU17$
Recovering rollback segment _SYSSMU18$
2.5
Thực hiện lại các bước từ 1.2 đến 1.5
=====================
Hãy
kết nối với tôi để được hỗ trợ tốt nhất về Oracle Database, RAC, ASM, Security,
Tunning, Troubleshooting, DataGuard, GoldenGate, Solaris, Linux, AIX và
WebLogic:
👨👩👧👦 KHUYẾN MẠI 50% khóa học online "Quản trị CSDL Oracle 12c cơ bản"
tại Unica, sở hữu trọn đời, học mọi lúc mọi nơi, ƯU ĐÃI ĐẶC BIỆT CHO 100
bạn đầu tiên với giá 399K (giá
gốc 800K) http://Bit.ly/2pq9Pxx
📧
Mail: tranbinh48ca@gmail.com
☎️
Mobile: 090.29.12.888
⚡️
Skype: tranbinh48ca
👨👩👧👦 Group FB: https://www.facebook.com/groups/413698089218929
Hãy
comment những nội dung mà bạn quan tâm xuống bên dưới✏️✏️✏️, tôi sẽ ở bên cạnh
và hỗ trợ cho bạn trên con đường trở thành DBA Oracle Expert
👨🏫👨🏫👨🏫
Cảm ơn
các bạn 😎😎😎
