8.1.SỬ DỤNG CÁC REDO LOG FILES,
8.1.1. Redo
log file
Oracle server sử dụng các online redo log files để giảm thiểu
việc mất mát dữ liệu trong database. Redo log files ghi lại tất cả các thay đổi
trong database buffer cache trừ một vài ngoại lệ ghi dữ liệu trực tiếp.
Redo log files được sử dụng đến khi instance gặp sự cố và ta
muốn khôi phục lại các dữ liệu đã commit nhưng chưa kịp ghi lên data files.
Redo log files chỉ được sử dụng trong trường hợp khôi phục dữ liệu.
8.1.2. Online
Redo Log Groups
§ Là nhóm các bản sao riêng biệt của các online redo log files được gọi
là online redo log group.
§ Background process LGWR thực hiện việc ghi đồng thời các
thông tin tương tự nhau vào các member thuộc cùng một group. Khi một group đầy
sẽ tiếp tục chuyển sang ghi dữ liệu trên group tiếp theo.
§ Oracle server, thông thường, cần ít nhất 02 online redo log file
groups để có thể vận hành một database.
8.1.3. Online
Redo Log Members
§ Mỗi một online redo log file trong một group được gọi là một member
(thành viên).
§ Mỗi member trong một nhóm có một số thứ tự (log sequence numbers)
phân biệt và các member này có cùng
một kích thước. Số thứ tự được gán mỗi khi Oracle server bắt đầu ghi dữ
liệu vào log group để có thể phân biệt được các redo log file duy nhất. Số log
sequence number được lưu trữ trong control file và trong phần header của tất cả
các data files.
8.1.4. Nội
dung của Online Redo Log Files (Members)
Online redo log files lưu trữ các redo records hay
còn được gọi là các redo entries.
Mỗi redo record là một nhóm các change vectors (vector
thay đổi dữ liệu), trong đó mỗi vector đặc trưng cho một sự thay đổi
trên một block dữ liệu thuộc database. Ví dụ, khi ta thay đổi giá trị lương
trong bảng employee, Oracle sẽ tạo ra một redo record lưu trữ lại việc thay đổi
dữ liệu của data segment block, rollback segment block và transaction table tương
ứng với thay đổi dữ liệu nói trên.
Các redo entries lưu trữ lại các dữ liệu để
từ đó ta có thể tái tạo lại các thay đổi dữ liệu trong database, bao gồm cả
rollback segments. Khi thực hiện phục hồi (recover) database sử dụng redo data,
Oracle sẽ đọc các change vectors có trong các redo records rồi áp các thay đổi
này vào các blocks tương ứng.
Các redo records được lưu trữ trong bộ nhớ
đệm SGA. Mỗi khi thực hiện commit một transaction, LGWR
sẽ ghi lại các redo records của
transaction đó từ các redo log buffer thuộc SGA vào một online redo log file,
và gán một số hiệu system change number (SCN)
cho transaction đã được commit đó. Chi khi các redo records thuộc transaction
đã được lưu trữ an toàn trên đĩa thì user process mới được nhận thông báo:
transaction has been committed.
Các redo records có thể được ghi vào online
redo log file trước khi transaction tương ứng được commit. Khi redo log buffer
đầy, hoặc khi transaction commit, LGWR sẽ đẩy
tất cả các redo log entries trong redo log buffer ra online redo log file, ngay
cả khi redo records có thể chưa được commit để khi cần, Oracle có thể khôi phục
(roll back) lại các thay đổi này.
8.1.5. Active
và Inactive Online Redo Log Files
Tại mỗi một thời điểm, Oracle chỉ sử dụng một trong số các
online redo log files để lưu trữ các redo records có trong redo log buffer.
Online redo log file đó ở trạng thái sẵn sàng cho việc ghi dữ liệu, nó được gọi
là current
online redo log file.
Các online redo log files cần thiết cho việc khôi phục
instance được gọi là active online redo log files. Trái lại,
các online redo log files không cần thiết cho việc khôi phục instance được gọi
là inactive.
Khi quản trị viên database đặt chế độ enable archiving,
Oracle sẽ không thể tái sử dụng hay ghi đè lên các active online log file cho tới
khi ARCn lưu trữ hết các nội dung của nó. Trong trường hợp disable
archiving, khi online redo log file cuối cùng được điền đầy, việc lưu ra file sẽ
được tiếp tục thực hiện đối với active file đầu tiên.
8.1.6. Thiết
lập các Redo Log Files khởi tạo
Việc khởi tạo ban đầu tập hợp các online redo log file bao gồm
các groups và các members được thực hiện trong quá trình tạo database.
Các tham số dưới đây xác định các giới hạn và số lượng của
online redo log files:
§ Tham số MAXLOGFILES
trong lệnh CREATE DATABASE xác định số lượng tối đa các
online redo log groups. Số lượng tối đa cho MAXLOGFILES là 255.
§ Tham số MAXLOGMEMBERS trong lệnh CREATE DATABASE quy định số lượng tối đa các members có trong mỗi group.
§ Tham số khởi tạo LOG_FILES xác định số lượng tối đa các log groups có thể được mở trong
database tại thời điểm hiện thời. Giá trị này không được vượt quá giá trị MAXLOGFILES*MAXLOGMEMBERS.
8.2.LGWR,
LOG SWITCHES VÀ CHECKPOINTS
8.2.1. Redo
Log Buffer và Background process LGWR
Oracle Server sẽ tuần tự ghi lại các thay đổi đối với
database có trong redo log buffer. Redo log buffer được sử dụng theo kiểu
xoay vòng. Theo đó, các redo entries sẽ được tiên trình nền LGWR ghi vào một trong các online redo log groups
gọi là online redo log group hiện thời (current) theo các tình huống sau:
§ Khi commit một transaction
§ Khi redo log buffer đã đầy
§ Khi LGWR vượt quá thời gian timeout (3 giây)
§ Trước khi DBWR ghi các blocks bị thay đổi trong database buffers cache vào trong
các data files
Các members trong một redo log group được tiến trình LGWR ghi lên đó với cùng một nội dung dữ liệu. Cho
nên không có khác biệt giữa các members trong một log group mà chỉ có sự khác
nhau giữa các members ở các log group khác nhau.
8.2.2. Log
Switches
LGWR ghi dữ liệu lên các
online redo log files một cách tuần tự, tức là mỗi khi online redo log group được
ghi đầy, LGWR sẽ lại chuyển sang ghi lên
group tiếp theo. Khi online redo log file cuối cùng được ghi đầy, LGWR sẽ lại quay trở về online redo log group đầu
tiên và lại bắt đầu quá trình ghi.
Log switch là sự kiện xảy ra khi LGWR dừng việc ghi trên một online redo log group
và chuyển sang ghi trên online redo log group khác. Quản trị viên database cũng
có thể thực hiện các log switches bằng tay. Mỗi khi xảy ra log switch, LGWT sẽ ghi dữ liệu lên log group mới và nó gán một
số hiệu duy nhất để xác định được các redo entries vừa lưu giữ.
Mỗi khi xảy ra sự kiện log switch đồng thời một sự kiện
checkpoint cũng sẽ được khởi tạo.
8.2.3. Checkpoints
Khi có checkpoints thì:
§ Tất cả các dữ liệu trong database buffers đã bị thay đổi, tính cho đến
thời điểm xảy ra checkpoint, sẽ được Background process DBWR ghi
lên datafiles.
§ Background process CKPT cập nhật phần headers của các
data files và các control files.
Checkpoints có thể xảy ra đối với tất cả các data files
trong database hoặc cũng có thể xảy ra với một data files cụ thể.
Checkpoint xảy ra theo các tình huống sau:
§ Mỗi khi có log switch
§ Khi một shut down một instance với các chế độ trừ chế độ abort
§ Xảy ra theo như thời gian quy định trong các tham số khởi tạo LOG_CHECKPOINT_INTERVAL (default =0, không cần thay đổi) và
LOG_CHECKPOINT_TIMEOUT (default là 1800s = 30p, không cần thay đổi)
§ Khi có yêu cầu trực tiếp của quản trị viên (DBA gõ ALTER SYSTEM CHECKPOINT; hoặc ALTER SYSTEM SWITCH LOGFILE;)
Thông tin về checkpoint được lưu trữ trong Alert file
trong trường hợp các tham số khởi tạo LOG_CHECKPOINTS_TO_ALERT được
đặt là TRUE.
Và ngược lại với giá trị FALSE.
Ví dụ:
-- Check tham số checkpoint
SQL> show parameter checkpoint;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean TRUE
-- Alert log thể hiện checkpoint 30p thực hiện 1 lần (do tham số log_checkpoints_to_alert =TRUE)
Tue Aug 10 22:37:29 2021
Incremental checkpoint up to RBA [0x30fb9.641a43.0], current log tail at RBA [0x30fba.51ea9.0]
Tue Aug 10 22:42:09 2021
Completed checkpoint up to RBA [0x30fba.2.10], SCN: 13269167187657
Tue Aug 10 23:05:00 2021
Beginning log switch checkpoint up to RBA [0x30fbb.2.10], SCN: 13269181935164
Thread 1 advanced to log sequence 200635 (LGWR switch)
Current log# 10 seq# 200635 mem# 0: +DATA_dbaviet/dbaviet/onlinelog/group_10.910.871600837
Current log# 10 seq# 200635 mem# 1: +RECO_dbaviet/dbaviet/onlinelog/group_10.6963.871600839
Tue Aug 10 23:05:00 2021
LNS: Standby redo logfile selected for thread 1 sequence 200635 for destination LOG_ARCHIVE_DEST_2
Tue Aug 10 23:05:25 2021
Archived Log entry 1334161 added for thread 1 sequence 200634 ID 0xb575a65f dest 1:
Tue Aug 10 23:07:20 2021
Completed checkpoint up to RBA [0x30fbb.2.10], SCN: 13269181935164
Tue Aug 10 23:08:28 2021
Incremental checkpoint up to RBA [0x30fbb.2d8e99.0], current log tail at RBA [0x30fbb.2f170c.0]
Tue Aug 10 23:21:55 2021
Beginning log switch checkpoint up to RBA [0x30fbc.2.10], SCN: 13269188528230
Thread 1 advanced to log sequence 200636 (LGWR switch)
Current log# 9 seq# 200636 mem# 0: +DATA_dbaviet/dbaviet/onlinelog/group_9.911.871600831
Current log# 9 seq# 200636 mem# 1: +RECO_dbaviet/dbaviet/onlinelog/group_9.6964.871600835
Tue Aug 10 23:21:55 2021
LNS: Standby redo logfile selected for thread 1 sequence 200636 for destination LOG_ARCHIVE_DEST_2
Tue Aug 10 23:22:19 2021
Archived Log entry 1334167 added for thread 1 sequence 200635 ID 0xb575a65f dest 1:
Tue Aug 10 23:27:04 2021
Completed checkpoint up to RBA [0x30fbc.2.10], SCN: 13269188528230
8.3.LÊN
KẾ HOẠCH SỬ DỤNG REDO LOG FILES
8.3.1. Xác
định số lượng Online redo log files
Để xác định số lượng các online redo log files
sử dụng cho phù hợp với database ta cần phải kiểm tra với nhiều cầu hình khác
nhau.
Trong một số trường hợp, một database instance
chỉ cần tới 02 groups. Tuy nhiên, trong một số trường hợp khác, một database
instance lại có thể cần tới nhiều groups hơn để có thể luôn đảm bảo có các
groups sẵn dùng cho LGWR. Ví dụ, khi các thông điệp ghi trong trace
file hay Alert file cho biết LGWR thường xuyên phải chờ một group do vẫn chưa kết
thúc được checkpoint, hoặc do group vẫn chưa được lưu trữ (archived) thì lúc này
là lúc ta cần thêm mới các groups.
Mặc dù Oracle server cho phép sử dụng nhiều
groups với số lượng members trong nó là khác nhau, ta vẫn nên cố gắng xây dựng
một cấu hình cân đối (số lượng các members trong các group nên là bằng nhau).
8.3.2. Nơi
đặt các Online Redo Log Files
Khi sử dụng đồng thời nhiều online redo log
files, ta nên đặt các members của một group trên các phần đĩa khác nhau. Một điều
lưu ý là khi một member nào đó không sẵn dùng (available) mà các members khác là
sẵn dùng thì instance cũng không thể shut down được.
Việc tách biệt các archive log files và online
redo log files trên các phần đĩa khác nhau, có thể làm giảm bớt xung đột giữa các
background process ARCH và LGWR.
Các data files và online redo log files nên đặt
trên các phần đĩa khác nhau để giảm bớt xung đột giữa LGWR và DBWR hạn chế việc mất dữ liệu ở cả data files và
online redo log files trong trường hợp hỏng ổ đĩa.
8.3.3. Xác
định kích thước cho các Online Redo Log Files
Kích thước tối thiểu của một online redo log
file là 50 K còn kích thước tối đa thì tuỳ thuộc vào hệ điều hành. Các members
thuộc các groups khác nhau có thể có các kích thước khác nhau; Tuy nhiên ta nên
đặt kích thước giống nhau giữa các members này.
Việc sử dụng các groups có kích thước khác nhau
chỉ nên thực hiện một cách tạm thời khi ta muốn thay đổi kích thước của các
members. Trong trường hợp này, ta cần tạo các online redo log groups mới với kích
thước khác, rồi sau đó loại bỏ (remove) các groups cũ đi.
Một số tình huống ảnh hưởng tới cấu hình của các
online redo log files:
§ Số lượng các log switches và checkpoints
§ Số lượng và độ lớn của các redo entries
§ Độ lớn của vùng không gian lưu trữ thứ cấp
8.3.4. Lưu
trữ các redo log files
Quản trị viên database cần phải quyết định đặt chế độ ARCHIVELOG
hay chế độ NOARCHIVELOG
cho database.
Chế độ NOARCHIVELOG
Với chế độ NOARCHIVELOG, các online redo
log files sẽ bị ghi đè mỗi khi online redo log file đã ghi đầy và xảy ra log
switches. LGWR sẽ không ghi đè lên redo log
group cho tới khi kết thúc checkpoint của group đó
Chế độ ARCHIVELOG
Trong trường hợp database được thiết lập ở chế độ ARCHIVELOG,
các groups đã đầy, mặc dù ở trạng thái inactive sẽ vẫn được lưu giữ. Do tất cả
các thay đổi trong database đều được ghi lại trong các online redo log files,
quản trị viên database có thể sử dụng phương pháp sao chép vật lý (physical
backup) và có thể khôi phục lại các dữ liệu đã commit trong database mà không sợ
bị mất dữ liệu.
Có hai hình thức lưu trữ các online redo log files:
§ Thực hiện lưu trữ bằng tay (manually). Lưu trữ các redo log file đã đầy
theo lệnh của quản trị viên database.
§ Lưu trữ tự động (automatically). Lưu trữ các redo log file đã đầy mỗi
khi xảy ra log switch.
Tham số LOG_ARCHIVE_START trong parameter file xác định các chế độ
lưu trữ này.
§ LOG_ARCHIVE_START
= TRUE, thực hiện lưu trữ ở chế độ tự động
§ LOG_ARCHIVE_START
= FALSE, thực hiện lưu trữ ở chế độ manually
8.4.ĐIỀU
KHIỂN LƯU TRỮ SAU ĐỐI VỚI PRIMARY/STANDBY
Oracle cung cấp cơ chế điều khiển switch các online redo log
group dựa theo thời gian (time-based). Trong cấu hình primary/standby, tất cả các
noncurrent logs tại primary site sẽ được lưu trữ rồi vận chuyển tới standby
database. Việc này sẽ hiệu quả khi hạn chế số lượng các redo records.
Việc thực hiện lưu trữ sau
là vì standby database cho tất cả các thay đổi trên online redo log tại primary
database được lưu trữ sau. Để điều khiển việc lưu trữ sau này, ta cần sử dụng
tham số
ARCHIVE_LAG_TARGET.
Việc thiết lập tham số này cho phép ta hạn chế, cũng như xác định được khoảng
thời gian được sử dụng cho lưu trữ sau.
8.4.1. Thiết
lập tham số ARCHIVE_LAG_TARGET
Khi thiết lập tham số khởi tạo ARCHIVE_LAG_TARGET
, Oracle
sẽ kiểm tra theo định kỳ thời gian các online redo log của instance hiện thời và
phát sinh các log switch theo các điều kiện sau:
§ Giả sử ban đầu, current log được tạo sau n giây và sau đó lại
mất m
giây để lưu current log ra đĩa. Khi này khoảng thời gian n + m sẽ tương ứng với giá trị của tham số ARCHIVE_LAG_TARGET.
Tham số
ARCHIVE_LAG_TARGET
cho biết giới hạn trên về thời gian (tính theo đơn vị giây) mà current log cần
sử dụng. Do thời gian lưu trữ không chính xác bằng khoảng thời gian log switch.
Giá trị 0 tương ứng với việc không thực hiện
chức năng log switching. Đây là giá trị thiết lập mặc định.
Ta có thể đặt giá trị cho
tham số
ARCHIVE_LAG_TARGET
ngay cả khi database không ở trong chế độ sao lưu (standby database). Ví dụ,
tham số ARCHIVE_LAG_TARGET
có thể được thiết lập để bắt buộc các logs phải thực hiện thao tác switch và lưu
trữ lên ổ đĩa. ARCHIVE_LAG_TARGET là một tham số
động và ta có thể thay đổi giá trị của tham số này thông qua câu lệnh ALTER SYSTEM SET.
8.4.2. Các yếu tố ảnh hưởng tới tham số
ARCHIVE_LAG_TARGET
Tham số
ARCHIVE_LAG_TARGET sẽ trở nên không
hữu dụng khi log được switch trong một khoảng thời gian quá ngắn. Tuy nhiên,
trong trường hợp các redo được tạo ra với tốc độ không đều như nhau, thì khoảng
thời gian ngắt quãng (interval) sẽ đưa ra giới hạn trên đối với current log.
Khi database ở trong trạng thái nghỉ (idle) và redo records không được tạo ra
thì, sau khoảng thời gian interval, log switch sẽ xảy ra và đẩy và ghi tất cả các redo records lên standby database.
Trong trường hợp
ARCHIVE_LAG_TARGET
được thiết lập với giá trị quá thấp thì cũng không tốt cho hệ thống về mặt hiệu
suất. Là vì hệ thống liên tục phải thực hiện các log switches. Do vậy ta nên chọn
giá trị hợp lý để nâng cao hiệu suất hệ thống.
8.5.XÁC
ĐỊNH CHẾ ĐỘ LƯU TRỮ
Để biết được các thông tin về việc lưu trữ, ta có thể sử dụng
một số cách sau:
8.5.1. Sử
dụng lệnh Server Manager
Câu lệnh này cho biết chế độ log của database.
Ví dụ:
SVRMGR> ARCHIVE LOG LIST
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination ?/dbs/arch
Oldest online log sequence 688
Current log sequence 689
8.5.2. Sử
dụng thông tin trong data dictionary
Ta cũng có thể sử dụng thông tin trong các data dictionary
views: V$DATABASE
và V$INSTANCE.
Ví dụ:
SVRMGR> SELECT name, log_mode
2> FROM
v$database;
NAME LOG_MODE
--------- ---------
U15 NOARCHIVELOG
1 row selected.
SVRMGR> SELECT archiver
2> FROM v$instance;
ARCHIVE
---------
STOPPED
1 row selected.
Ta cũng có thể xem các thông tin liên quan đến các groups và
các members thông qua views data dictionary V$THREAD, V$LOG.
Các thông tin cần quan tâm:
§ V$THREAD:
GROUPS, CURRENT_GROUP#, SEQUENCE#
§ V$LOG:
GROUP#, MEMBERS, STATUS, SEQUENCE#, BYTES
Ví dụ:
SVRMGR>SELECT
groups, current_group#,sequence#
2>FROM v$thread;
GROUPS CURRENT_GR SEQUENCE#
---------- ---------- ----------
2 1 689
1 row selected.
SVRMGR>SELECT
group#,sequence#,bytes,members,status
2>FROM v$log;
GROUP# SEQUENCE# BYTES
MEMBERS STATUS
--------- ---------- -------- --------- -------
1 688 1048576
1 CURRENT
2 689 1048576
1 INACTIVE
2 rows selected.
Trong câu lênh ở trên, giá trị của cột STATUS
được biểu hiện như sau:
§
UNUSED chỉ ra online redo log
group vẫn chưa được sử dụng. Trạng thái này tương ứng với việc online redo log
file mới được thêm vào.
§ CURRENT
chỉ ra rằng online redo log group đang được sử dụng. Nó cũng ngầm đinh luôn trạng
thái active đối với các online redo log group này.
§ ACTIVE:
trạng thái này ứng với the online redo log group vẫn đang được sử dụng nhưng
không phải là online redo log group hiện thời.
§ INACTIVE
chỉ ra online redo log group không còn cần thiết cho việc khôi phục instance.
Để xác định tên của tất cả các member trong một group, ta có
thể tra cứu thông tin trong V$LOGFILE: GROUP#, STATUS, MEMBER
Ví dụ:
SVRMGR>SELECT
*
2>FROM
v$logfile;
GROUP# STATUS MEMBER
---------- ------- -----------------------------
1 /DISK3/log1a.rdo
2 /DISK4/log2a.rdo
8.6.ĐIỀU
KHIỂN CÁC LOG SWITCHS VÀ CHECKPOINTS
8.6.1. Thực
hiện log switches
Log switches và checkpoint là các sự kiện xảy ra một cách tự
động mỗi khi online redo log group đầy. Tuy nhiên, ta vẫn có thể phát sinh các Log
switchs thông qua lệnh của Server Manager.
SVRMGR>ALTER
SYSTEM SWITCH LOGFILE;
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1. Sử dụng Backup Manager
2. Chọn Subsystem
3. Chọn Logfile --> Switch logfile
8.6.2. Thực
hiện checkpoint
Ta cũng có thể phát sinh các Checkpoints thông qua lệnh:
SVRMGR>ALTER
SYSTEM CHECKPOINT;
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1. Sử dụng Backup Manager
2. Chọn Subsystem
3. Chọn Logfile --> Force checkpoint
8.6.3. Điều
chỉnh các ngắt quãng checkpoints
Trong trường hợp database sử dụng các online redo log files
lớn, ta có thể điều chỉnh lại các ngắt quãng đối với online redo log file đó
thông qua các tham số:
§ LOG_CHECKPOINT_INTERVAL: Số lượng blocks (tính theo số block của hệ điều hành) lớn nhất để
thực hiện một checkpoint
§ LOG_CHECKPOINT_TIMEOUT: Khoảng thời gian lớn nhất (tính theo đơn vị giây) để thực hiện một
checkpoint.
8.7.QUẢN TRỊ CÁC REDO LOG FILES
8.7.1. Bổ
sung các online redo log groups
Trong một vài trường hợp, ta có thể cần tới việc nạp thêm
các log groups hay các log members.
Cú pháp:
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] filespec
[, [GROUP integer] filespec]...]
Hình vẽ 5.
Bổ sung online redo log groups
Với câu lệnh trên, ta cần chỉ ra tên và đường dẫn của các
members trong từng group cụ thể. Giá trị của tham số GROUP
được chọn tương ứng với mỗi redo log file group. Trong trường hợp bỏ qua tham số
này, Oracle server sẽ tự động sinh ra các giá trị thích hợp.
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1. Sử dụng Backup Manager
2. Chọn Subsystem
3. Chọn Logfile --> Add Logfile Group
8.7.2. Bổ
sung các online redo log members
Tương tự như các group, ta cũng có thể thêm mới các member
cho từng group bằng câu lệnh SQL
ALTER DATABASE [database]
ADD LOGFILE MEMBER
[ 'filename' [REUSE]
[,'filename' [REUSE]]...
TO {GROUP integer
|('filename'[, 'filename']...)
}
]...
Lưu ý: tên file được chỉ ra cần kèm theo đường dẫn đầy đủ.
Trong trường hợp không có đường dẫn, file sẽ được xem như được đặt trong thư mục
mặc định. Nếu file thêm mới đã tồn tại, ta cần thêm vào tuỳ chọn REUSE.
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1. Sử dụng Backup Manager
2. Chọn Subsystem
3. Chọn Logfile --> Add Logfile Member
8.7.3. Định
lại chỗ cho các redo log file
Trong một vài trường hợp, ta cần phải dịch chuyển các file
redo log tới một vị trí khác, để đảm bảo an toàn chẳng hạn. Khi này, ta cần thực
hiện theo các bước sau:
1. Tắt database.
2. Sao chép các online redo log files tới một địa điểm mới.
3. Restart database ở chế độ mount.
4. Thực hiện lệnh ALTER DATABASE RENAME FILE để thay đổi con trỏ trong control file, trỏ tới một đường dẫn file
mới.
5.
Mở lại database (Lệnh: ALTER
DATABASE OPEN).
Câu lệnh đổi tên file:
ALTER DATABASE [database]
RENAME FILE 'filename'[, 'filename']...
TO 'filename'[, 'filename']...
Lưu ý: Phải tồn tại file ở đường dẫn mới chỉ
ra.
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1. Sử dụng Backup Manager
2. Chuyển tới nút Logfile Group
3. Chọn log file group tương ứng
4. Thay đổi tên file trong trường thuộc tính.
8.7.4. Ngừng
sử dụng các Online redo log groups
Để có thể thay đổi kích thước các online redo log groups, ta
có thể thêm mới các online redo log group và xoá bỏ các online redo log group
đã có.
Sử dụng lệnh của Server Manager để ngưng sử dụng online redo
log group:
ALTER DATABASE [database]
DROP LOGFILE
{GROUP integer|('filename'[,
'filename']...)}
[,{GROUP integer|('filename'[,
'filename']...)}]...
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1.
Sử dụng Backup Manager
2.
Chuyển tới nút Logfile Group
3.
Chọn log file group tương ứng
4.
Chọn Logfile --> Drop
Logfile Group
5.
Bấm nút OK.
Một số điểm cần lưu ý
khi xoá log groups
§ Một instance cần ít nhất hai nhóm (group) các online redo log files.
§ Không thể huỷ (drop) group đang ở trạng thái active.
§ Khi huỷ một online redo log group, thực chất ta chỉ huỷ về mặt logic
mà thôi. Oracle sẽ không tiếp tục quản lý nó nữa. Tuy nhiên, các file sẽ vẫn
còn và không bị xoá bởi hệ điều hành.
8.7.5. Ngừng
sử dụng các Online redo log members
Sử dụng lệnh của Server Manager để ngưng sử dụng online redo
log member:
ALTER DATABASE [database]
DROP LOGFILE MEMBER 'filename'[,
'filename']...
Trong Oracle Enterprise Manager – OEM, ta làm theo các bước
sau:
1.
Sử dụng Backup Manager
2.
Chuyển tới nút Logfile Group
3.
Chọn log file group tương ứng
4.
Chọn Logfile --> Drop
Logfile Member
5.
Bấm nút OK.
Một số điểm cần lưu ý
khi xoá log members
§ Không thể ngừng sử dụng member của group mà có trạng thái là VALID.
§ Nếu group đang trong trạng thái active, ta cần phải thực hiện log
switch để chuyển sử dụng sang một log group khác trước khi ngưng sử dụng các
member của group hiện thời.
§ Khi huỷ một online redo log member, thực chất ta chỉ huỷ về mặt
logic các file vẫn không bị xoá bởi hệ điều hành.
8.7.6. Xoá
rỗng Online redo log file
Trong một vài trường hợp các members bị lỗi, quản trị viên
database có thế xử lý bằng cách khởi tạo lại các log file thông qua lệnh SQL để
khởi tạo lại:
ALTER DATABASE CLEAR LOGFILE
Cú pháp:
ALTER DATABASE [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer|('filename'[,
'filename']...)}
[,{GROUP integer|('filename'[,
'filename']...)}]...
Sử dụng lệnh này cũng tương đương với việc thêm mới các
online redo log file và xoá bỏ các redo log file hiện thời.
Lưu ý:
Khi xoá rỗng logfile mà nó không dùng để lưu trữ, ta cần bổ
sung từ khoá UNARCHIVED.
=============================
Website không bao giờ chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn muốn tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ kinh nghiệm, thủ tục, quy trình, bí kíp thực chiến mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin1_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
=============================
Website không bao giờ chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn muốn tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ kinh nghiệm, thủ tục, quy trình, bí kíp thực chiến mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin1_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
HỌC ORACLE DATABASE CƠ BẢN TỪ A-Z - BÀI 8: QUẢN LÝ REDO LOG FILES, CHECKPOINTS, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
