In database management, the logging system is a critical component for ensuring data integrity and system recovery. In GBase 8s, both physical and logical logs play vital roles in system recovery and data management. This article explores the structure, functionality, and importance of these logs in database management.
Physical Logs: The Foundation of Fast Recovery
Physical logs record all physical operations in the database, such as modifications, insertions, and deletions of data pages. These records are essential for restoring the database to its state before a system failure.
Key Facts About Physical Logs:
- Used during fast recovery.
- Often set too small in most customer systems, leading to frequent checkpoints.
- Can be moved outside the root dbspace, which is generally recommended.
- Crucial for GBase 8s's fast recovery mechanism and its archiving algorithm, especially in environments prone to power failures and disk crashes.
Common Pitfalls:
- The initial size of the physical log is often too small, causing frequent checkpoints. This is a common mistake made by novice administrators.
Physical Log Page Structure:
The page structure of the physical log is similar to that of regular data pages but with key differences. Physical log pages contain the address of the original page location rather than the physical location in the log. This allows for accurate data restoration during recovery.
The image above shows the structure of a physical log page. The page in the physical log is identical to its original page. The only way to determine that a page is from the physical log is by examining the page address (offset and block). The page contains the address of the original page location, not its physical location in the log.
Logical Logs: Ensuring Data Consistency
Logical logs can be thought of as a sequence of log pages, each with a page offset equivalent to a logical page number.
Key Characteristics:
- Each logical log is a continuous sequence of log pages, numbered starting from 0.
- Log files are segments within a block and are continuously overwritten. They serve as temporary hosts for logical logs.
- Logical logs can contain any number of pages, from 1 to the total available in the log file.
- Logical log pages are generated one after another in the logical log buffer and written out sequentially each time the buffer is flushed.
Logical Log Page Structure:
As shown in the image above, the structure of a logical log page suggests a sequential method of accessing log records. For example, note that the page does not have a slot table (the length of each record is stored within the record itself). Also, logical log data flows smoothly from one page to the next without interruption (though records must be entirely contained within the log file). Even the page header has some unique attributes.
Unique Attributes of the Page Header:
- pg_nslots: Unused, as there is no real concept of slots on log pages.
- pg_frcnt: Always zero, even for partially filled pages (note that pg_frptr is accurate). This is more coincidental than by design.
- pg_next: Contains the unique ID of the logical log.
- pg_prev: Contains the page offset (similar to a logical page number) of the log page. Note that this is the offset within the log, starting from 0.
Logical Log Position:
Log records are uniquely addressed within a specific logical log. The address used is called the logical log position, or logpos. It is a 4-byte integer code that describes the location of the log record based on the page offset and byte offset. The page offset is relative to the start of the log, indexed from 0. The byte offset is relative to the start of the page, also indexed from 0, but should not be less than 0x018 due to the space occupied by the page header.
For example, if you are told that a logical log record is located in logical log 234 with a logpos of 0x12018, you would:
- Use the newer of the two checkpoint/logical log retention pages in the root chunk to find the physical address of log number 234.
- Once at that page, you would offset 0x12 pages within the log to find the correct log page.
- Then, offset 0x018 bytes within that page to find the log record.
Displaying Logical Logs
Displaying All Logical Log Files:
Use the onstat -l
command to display all logical log files. Logical log files have two numbers:
- File Number (number): This number remains constant.
- Unique ID (uniqid): Since logical log files are reused cyclically, a unique ID is needed to distinguish them.
[root@node2 ids]# onstat -l
On-Line -- Up 16 days 03:16:37 -- 19345028 Kbytes
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 98 256 13934 66 211.12
phybegin physize phypos phyused %used
2:53 32715 25656 4971 15.19
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-3 0 128 1408526 154832 116507 9.1 1.3
Subsystem numrecs Log Space used
OLDRSAM 1408450 141317188
HA 6 264
DDL 70 24360
address number flags uniqid begin size used %used
45b79a60 14 U-B---- 121 3:29483 3270 3270 100.00
45b79ac8 13 U-B---L 122 3:26213 3270 3270 100.00
45b79b30 12 U-B---- 123 3:22943 3270 3270 100.00
45b79b98 11 U-B---- 124 3:19673 3270 3270 100.00
45b79c00 10 U-B---- 125 3:16403 3270 3270 100.00
45b79c68 9 U-B---- 126 3:13133 3270 3270 100.00
45b79cd0 8 U-B---- 127 3:9863 3270 3270 100.00
45b79d38 7 U-B---- 128 3:6593 3270 3270 100.00
45b79da0 6 U-B---- 129 3:3323 3270 3270 100.00
45b79e08 5 U-B---- 130 3:53 3270 3270 100.00
45b79e70 1 U-B---- 131 3:32753 3270 3270 100.00
45b79ed8 2 U-B---- 132 3:36023 3270 3270 100.00
45b79f40 3 U-B---- 133 3:39293 3270 3270 100.00
45b79fa8 4 U-B---- 134 3:42563 3270 3270 100.00
4538df30 15 U-B---- 135 3:45833 3270 3270 100.00
4538df98 16 U-B---- 136 3:49103 3270 3270 100.00
4545ce28 17 U---C-- 137 3:52373 3270 2411 73.73
485196a0 18 U-B---- 120 3:55643 3270 3270 100.00
48acbed8 19 A------ 0 3:58913 3270 0 0.00
19 active, 19 total
Displaying Logical Log Content:
Use the onlog
command to display the content of logical logs. Specific usage details are not covered here.
Conclusion
By exploring the physical and logical logs in GBase 8s, we gain a deeper understanding of their structure, functionality, and importance in database management and recovery. This article aims to provide valuable insights and inspiration, helping you better manage and maintain your GBase database systems.
Top comments (0)