Oracle 12c, xử lý sự cố file bị corrupt

Tham khảo:

http://www.dba-oracle.com/t_repair_corrupt_blocks.htm

https://oracle-base.com/articles/misc/detect-and-correct-corruption

Dealing with Oracle Database Block Corruption

https://jhdba.wordpress.com/2010/04/14/identifying-corrupt-blocks/

https://blog.dbi-services.com/rman-backup-is-failing-due-to-qcorrupt-blocksq/

 

Thường gặp lỗi này là do ổ đĩa bị lỗi

Oracle cung cấp view đê chúng ta kiểm tra

select * from v$database_block_corruption

Hoặc nếu ta biết chính xác file và block bị lỗi có thể chạy query sau để biết chính xác khối bị lỗi:

select 
   relative_fno, 
   owner, 
   segment_name, 
   segment_type
from 
   dba_extents
where 
   file_id = 6
and 
   437 between block_id and block_id + blocks – 1;

Lệnh này mapping luôn ra segment bị lỗi

SELECT DISTINCT owner, segment_name
FROM v$database_block_corruption dbc
JOIN dba_extents e ON dbc.file# = e.file_id AND dbc.block# BETWEEN e.block_id and e.block_id+e.blocks-1
ORDER BY 1,2;

Như mô tả của link

Dealing with Oracle Database Block Corruption

RMAN > validate check logical database

Thấy có dòng validate found one or more corrupt blocks

RMAN > blockrecover corruption list

Một lần nữa cùng nguyên nhân trên, ta lặp lại validate check logical database & blockrecover corruption list trong rman để giải quyết vấn đề

Cập nhật quan trọng trong trường hợp không có backup

Ta cần dùng lệnh scan toàn bộ database oracle tìm corrupt:

sau khi thực hiện lệnh này thì lỗi corrupt sẽ được tổng hợp trong view:

select * from V$DATABASE_BLOCK_CORRUPTION

Thường khối corrupt sẽ liên quan đến table hoặc index cụ thể, ta có lệnh sau để tổng hợp ra chúng:

SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
– greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks – 1
AND e.block_id + e.blocks – 1 >= c.block#
UNION
SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
, header_block corr_start_block#
, header_block corr_end_block#
, 1 blocks_corrupted
, ‘Segment Header’ description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks – 1
UNION
SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
, greatest(f.block_id, c.block#) corr_start_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
– greatest(f.block_id, c.block#) + 1 blocks_corrupted
, ‘Free Block’ description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks – 1
AND f.block_id + f.blocks – 1 >= c.block#
order by file#, corr_start_block#;

Từ đó ta sẽ cần tạo lại table hoặc index để fix lỗi

Để kiểm tra fix được lỗi hay chưa ta nên lặp lại quy trình check

RMAN> BACKUP CHECK LOGICAL VALIDATE DATABASE;

Thật không may là việc chặn lại không thể sử dụng vì nó đòi hỏi một phiên bản Oracle Enterprise Edition và chúng tôi đang chạy Oracle Standard Edition.
Tôi cũng đã cố gắng để sửa chữa khối này với dbms_repair gói, nhưng dbms_repair không có bất kỳ tùy chọn để sửa chữa một khối bị hỏng có sản phẩm nào.
Sau một số phân tích sâu hơn, tôi quyết định để lại khối trống rỗng bị rạn nứt này vào cơ sở dữ liệu, như một khối không sử dụng bị hỏng không có hại.  Khi Oracle sẽ sử dụng lại khối này để gán nó cho một phân đoạn, Oracle sẽ tự động định dạng lại khối này, và vấn đề sẽ được giải quyết.

Advertisements

oracle 12c, khong the su dung system rollback

Tham khảo:

http://dbarohit.blogspot.com/2013/08/ora-01552-cannot-use-system-rollback.html

https://www.akadia.com/services/ora_crash_recovery.html

Lỗi khi chạy rman clone lỗi

ORA-01552: cannot use system rollback segment for non-system tablespace

Recently I have met with an issue where the undo tablespace of the Prod database is got corrupted and we required to create the new undo tablespace coz we had no undo backup. While creating the undo tablespace we got the following error:

SQL> create undo tablespace undotbs2
2  datafile ‘/u01/app/oracle/oradata/db1/undotbs01.dbf’ size 100m;
create undo tablespace undotbs2
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’
ORA-06512: at line 993
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’

I have implemented the same test case over my DEV server which was identical in nature with the Production servers.
Following are Environment.
                    Dev1 database: source.xxx.com
                    Dev2 database: target.xxx.com
                    Database Version: 11203
                    Golden gate Version: 11.1
                    Golden Gate schema: GGATE
                    Replication Method: DDL ACTIVE-ACTIVE Replication
I  moved the undo datafile at OS level.
[oracle@source ~]$ cd /u01/app/oracle/oradata/db1/

[oracle@source db1]$ ls -al undo*
-rw-r—– 1 oracle oinstall 188751872 Aug  1 11:59 undotbs01.dbf
[oracle@source ~]$mv undotbs01.dbf undotbs01.dbf.bkp

SQL> startup
ORACLE instance started.

Total System Global Area 1690705920 bytes
Fixed Size                  1345380 bytes
Variable Size            1006635164 bytes
Database Buffers          671088640 bytes
Redo Buffers               11636736 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 – see DBWR trace file
ORA-01110: data file 3: ‘/u01/app/oracle/oradata/db1/undotbs01.dbf’

Excerpts from alert log.
ALTER DATABASE OPEN
Errors in file /u01/app/oracle/diag/rdbms/db1/db1/trace/db1_dbw0_2626.trc:
ORA-01157: cannot identify/lock data file 3 – see DBWR trace file
ORA-01110: data file 3: ‘/u01/app/oracle/oradata/db1/undotbs01.dbf’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory

SQL> show parameter undo
NAME                                 TYPE        VALUE
———————————— ———– ——————————
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1
Now change the undo management parameter to MANUAL and then bounce the database.
SQL> alter system set undo_management=manual scope=spfile;
System altered.
SQL> shut immediate
SQL> startup mount
SQL> select FILE#,NAME,STATUS from v$datafile
  2  ;
     FILE# NAME                                               STATUS
———- ————————————————– ——-
         1 /u01/app/oracle/oradata/db1/system01.dbf           SYSTEM
         2 /u01/app/oracle/oradata/db1/sysaux01.dbf           ONLINE
         3 /u01/app/oracle/oradata/db1/undotbs01.dbf          ONLINE
         4 /u01/app/oracle/oradata/db1/users01.dbf            ONLINE
         5 /u01/app/oracle/oradata/db1/ggate_01.dbf           ONLINE
Lets drop the undo tablespace data file from database level in offline state.
SQL> alter database datafile ‘/u01/app/oracle/oradata/db1/undotbs01.dbf’ offline drop;
Database altered.
SQL> alter database open;
Database altered.
SQL> create undo tablespace undotbs2
  2  datafile ‘/u01/app/oracle/oradata/db1/undotbs02.dbf’ size 100m;
create undo tablespace undotbs2
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’
ORA-06512: at line 993
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’
SQL> drop tablespace undotbs1 including contents;
drop tablespace undotbs1 including contents
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’
ORA-06512: at line 993
ORA-01552: cannot use system rollback segment for non-system tablespace ‘GGATE’
SQL> !oerr ora 01552
01552, 00000, “cannot use system rollback segment for non-system tablespace ‘%s'”
// *Cause: Tried to use the system rollback segment for operations involving
//        non-system tablespace. If this is a clone database then this will
//        happen when attempting any data modification outside of the system
//        tablespace. Only the system rollback segment can be online in a
//        clone database.
// *Action: Create one or more private/public segment(s), shutdown and then
//         startup again. May need to modify the INIT.ORA parameter
//         rollback_segments to acquire private rollback segment. If this is
//         a clone database being used for tablspace point in time recovery
//         then this operation is not allowed.  If the non-system tablespace
//         has AUTO segment space management, then create an undo tablespace.
SQL>  select segment_name, status from dba_rollback_segs;
SEGMENT_NAME                   STATUS
—————————— —————-
SYSTEM                         ONLINE
_SYSSMU10_2490256178$          OFFLINE
_SYSSMU9_3593450615$           OFFLINE
_SYSSMU8_1909280886$           OFFLINE
_SYSSMU7_1924883037$           OFFLINE
_SYSSMU6_2460248069$           OFFLINE
_SYSSMU5_3787622316$           OFFLINE
_SYSSMU4_1455318006$           OFFLINE
_SYSSMU3_2210742642$           OFFLINE
_SYSSMU2_4228238222$           OFFLINE
_SYSSMU1_3138885392$           OFFLINE
11 rows selected.
SQL> select * from v$rollname;
       USN NAME
———- ————————————————–
         0 SYSTEM

Solution

To get rid of the above issues we need to disable the system triggers and then create the new undo tablespace. Once the tablespace is created now enable those triggers.
Make sure database is in OPEN mode.
SQL> alter system set “_system_trig_enabled” = FALSE;
System altered.
SQL>  alter trigger sys.cdc_alter_ctable_before DISABLE;
Trigger altered.
SQL> alter trigger sys.cdc_create_ctable_after DISABLE;
Trigger altered.
SQL> alter trigger sys.cdc_create_ctable_before DISABLE;
Trigger altered.
SQL> alter trigger sys.cdc_drop_ctable_before DISABLE;
Trigger altered.
SQL> create undo tablespace UNDOTBS2
  2  datafile ‘/u01/app/oracle/oradata/db1/undotbs02.dbf’ size 200m;
Tablespace created.
SQL> alter system set undo_tablespace=UNDOTBS2 scope=spfile;
System altered.
SQL> drop tablespace UNDOTBS1 including contents;
Tablespace dropped.
SQL> alter trigger sys.cdc_alter_ctable_before ENABLE;
Trigger altered.
SQL> alter trigger sys.cdc_create_ctable_after ENABLE;
Trigger altered.
SQL> alter trigger sys.cdc_create_ctable_before ENABLE;
Trigger altered.
SQL> alter trigger sys.cdc_drop_ctable_before ENABLE;
Trigger altered.
SQL> alter system set “_system_trig_enabled” = TRUE;
System altered.
SQL> alter system set undo_management=AUTO scope=spfile;
System altered.
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 1690705920 bytes
Fixed Size                  1345380 bytes
Variable Size            1006635164 bytes
Database Buffers          671088640 bytes
Redo Buffers               11636736 bytes
Database mounted.
Database opened.
SQL> show parameter undo
NAME                                 TYPE        VALUE
———————————— ———– ——————————
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS2
SQL> select name,status from v$datafile
  2  where name like ‘%undo%’;
NAME                                               STATUS
————————————————– ——-
/u01/app/oracle/oradata/db1/undotbs02.dbf          ONLINE

oracle 12c duplicate database using rman

Tham khao:

https://blog.pythian.com/duplicate-from-active-database-using-rman-step-by-step/

https://oracle-base.com/articles/11g/duplicate-database-using-rman-11gr2

Dung rman connec toi source db (target) va aulixi…

luu y copy dung folder to folder

Dung oradim de new instance…

Sau do startup nomount

RMAN> DUPLICATE DATABASE TO DB11G
FROM ACTIVE DATABASE
NOFILENAMECHECK;

Done

Oracle tạo database từ datafile sẵn có

Tham khảo links:

https://docs.oracle.com/database/121/NTQRF/create.htm#NTQRF050

http://www.dba-oracle.com/tips_oradim_utility.htm

Sử dụng oradim để tạo database

B1) Tạo file init.ora:

Ta có thể copy từ db đang chạy, nó locate ở ORACLE_BASE\admin\orcl\pfile\init.ora trong đó orcl là sid của database

chú ý chỉnh sửa các tham số đường dẫn như control_files

control_files=(“C:\app\Administrator\oradata\orcl\control01.ctl”, “C:\app\Administrator\fast_recovery_area\orcl\control02.ctl”)
db_recovery_file_dest=”C:\app\Administrator\fast_recovery_area”
db_recovery_file_dest_size=6420m

thông số RAM sga_target, và pga_aggregate_target

B2) Ta chạy oradim:

C:\> oradim -NEW -SID orcl -STARTMODE manual -PFILE “C:\app\username\admin\orcl\pfile\init.ora”

set password cho SYS DBA

C:\> oradim -EDIT -SID OPPRD -SYSPWD q123456

B3) Ta thử chạy database:

SQL> startup nomount;

Thì có thể gặp lỗi:

LRM-00109: could not open parameter file ‘C:\APP\ADMINISTRATOR\PRODUCT\12.1.0\DB
HOME_1\DATABASE\INITORCL.ORA’

Ta có thể copy từ database cũ về và chạy

hoặc dùng lệch startup nomount pfile=”

B4) Chúng ta cần sửa lại đường dẫn datafile nếu cần khi ở máy mới

Lấy danh sách datafiles

SQL> select name from v$datafile;

Dùng lệnh rename

SQL> alter database rename file ” to ”

để chỉnh

và nếu thiếu redo log => https://shrikantrao.wordpress.com/2011/07/14/recover-missing-online-redo-log/

Cần tham khảo cách trên

Việc thay đổi thông tin đường dẫn trong database có thể thực hiện theo cách nhanh hơn là dùng lệch

SQL> alter database backup controlfile to trace

khi đó control file chứa các thông tin của database được lưu tại ví trí được chỉ ra trong file alert.log

Nội dung kiểu như

CREATE CONTROLFILE REUSE DATABASE “ORCL” NORESETLOGS NOARCHIVELOG
MAXLOGFILES 255
MAXLOGMEMBERS 2
MAXDATAFILES 256
MAXINSTANCES 1
MAXLOGHISTORY 1134
LOGFILE
GROUP 1 ‘/oradata/ORCL/redo11.log’ SIZE 20M,
GROUP 2 ‘/oradata/ORCL/redo21.log’ SIZE 20M
DATAFILE
‘/oradata/ORCL/system.dbf’,
‘/oradata/ORCL/undo.dbf’,
‘/oradata/ORCL/data01.dbf’,
‘/oradata/ORCL/index01.dbf’
CHARACTER SET US7ASCII

Do đó ta có thể dễ dàng thự thi các thay đổi về đường dẫn

B5) Sau khi thực hiện tạo database copy datafile từ folder oradata ta nên khôi phục database về thời điểm mới nhất

bằng cách backup database bằng tool rman ở database hiện tại

RMAN> backup database;

tuy nhiên nếu database không chạy ở chế độ archivelog ta cần tắt database và bật lại ở chế độ mount để tiến hành backup.

Trong trường hợp không có file backup

Ta mở db có thể gặp lỗi:

alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘C:\APP\ADMINISTRATOR\…\SYSTEM01.DBF’

Ta thực hiện lệnh sau

SQL> recover database using backup controlfile until cancel;

Không có file backup nên ta chọn cancel, còn nếu có thì ta cho khôi phục tới thời điểm backup

Sau đó dùng lệnh

SQL> alter database open resetlogs;

Để mở database

ORACLE – CANNOT OPEN – khi mà relog file ở chế độ recover

Tham khảo:

http://oracleandunix.blogspot.com/2011/07/ora-01623-log-s-is-current-log-for.html

 

SQL> startup mount;
SQL> select * from v$logfile;
SQL> alter database open;
SQL> recover database using backup controlfile until cancel;
SQL> recover database
SQL> recover database  using backup controlfile;
=> filename: redo logfile to recover ở bước này
SQL> alter database open resetlogs;

Kết thúc





			

oracle – hiểu về kiến trúc

Một số blog tiếng việt có những bài nói về kiến trúc oracle rất hay, nên đọc:

Tham khảo:

https://trungquan710.com/oracle/kien-truc-oracle-database-11g-p3.html

Mình trích lọc những thứ quan trọng:

Control files

Đây là tập tin hết sức quan trọng với database, nếu không có nó sẽ không open được database. Tập tin này chứa metadata về database, như tên database, vị trí các data files, redo log files, thông tin về backup,…

Do là tập tin quan trọng, nên chúng ta cần nhân bản (multiplex) file này ra làm 2, 3 bản ở các vị trí lưu trữ khác nhau, để trong trường hợp 1 file bị hư vẫn còn các file còn lại, đảm bảo hệ thống hoạt động.

Các tập tin này hay có đuôi là .ctl

 

Online redo log files

Đây chính là các tập tin mà process LGWR ghi dữ liệu ra từ Redo log buffer. Các tập tin này cần thiết trong trường hợp instance crash, phải recover lại.

Các redo log files được chia vào các log group. Mỗi log group cũng nên có 2 redo log files trở lên (cũng multiplex như control file), để đảm bảo khi có 1 file hư thì vẫn còn file còn lại để hệ thống hoạt động.

Do được sử dụng xoay vòng, cần ít nhất 2 log group trong database.

 

Về redo logs, Khi hệ thống có nhiều update và giao dịch thì nên có nhiều redo log

Tham khảo: http://www.oracleracexpert.com/2013/07/thread-1-cannot-allocate-new-log.html

 

oracle switch log tự động

Một số vấn đề thường gặp khi dùng cơ sở dữ liệu Oracle là IO quá kém dẫn tới file redo log thường hay bị lỗi là không đọc và ghi được, lỗi IO của ổ đĩa, dẫn tới oracle sẽ bị treo nếu không được khắc phục…:D

Để giải quyết vấn đề chúng ta cần cơ chế tự động ghi ở redo log khác

HOW TO SWITCH ORACLE LOGS AUTOMATICALLY

Tham khảo tham số:

ARCHIVE_LAG_TARGET

Nó sẽ tự động thực hiện lệnh

ALTER SYSTEM SWITCH LOGFILE;

theo tần số thời gian!

https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams009.htm#REFRN10003

https://www.pythian.com/blog/rman-recipes-how-to-switch-oracle-logs-automatically/

đọc thêm về quản lý redo log

https://docs.oracle.com/cd/B19306_01/server.102/b14231/onlineredo.htm