Retrospective:

The project in itself was interesting and very satisfying. We do have comments and thoughts, and here they are. We are now in the 'integration' phase of the project. We feel VERY strongly that we should have implemented both the log and the recovery managers. We needed a basic functionality from the Log Manager, where the log was like a simple file to which we could write to, and read from. We discovered that the Log Manager group had made assumptions, some of which, in our eyes, were unnecessary.

For example, the Log Manager keeps track of the end of the log file with the help of their 'MAGIC' value. That is, they can recognize EOF when they see it, but need to perform a scan on the log in order to find it. So, when the log is first opened, they require that the Recovery Manager sit in a loop and find the end of file. It is only after this action is performed, can a log record be written. This defeats the idea of a Log Manager providing simple functions to write to and read from the log.
If the master lsn is invalid, it implies that the log file is empty and that there is no transaction that needs to be recovered. In such a case the Restart routine performs no actions. Now, when the Log Manager calls the GetEarliestLSN() function of the Recovery Manager ( for log compaction ), they require that we return a value '010', which is the physical address of the beginning of the log. This is a detail we'd rather not have to know about.

Both the points stated above, makes the Recovery Manager somehow 'know' the internal layout of the log, and the exact implementation of the Log Manager.

Another problem recently discovered is the problem with the logging of space maps. The Space Management group caches its own copy of the space map pages. After recovery, the copy of the space map in the cache of the Space Manager and the disk may be inconsistent. This is because the Recovery Manager treats the space map pages as any other data page. During the restart phase, the Recovery Manager may modify those pages in the buffer pool, and the Space Manager will not know about this. It will continue working with the incorrect version. We've found two possible solutions to the problem.

The Space Manager could modify pages in the buffer pool directly without caching any pages. This would be the simplest and cleanest solution.
An alternative would be for the Recovery Manager to modify the Space Manager's cached copies. This, we think would be a more messy solution, but faster to implement.

To conclude with, the project has been enjoyable and we've gained some knowledge on what it takes to build a system. The group meetings have been interesting and we learned several coding lessons.

Next: References Up: MINIREL : Recovery Manager

Previous: Testing:

ranjani ramamurthy
Sat May 13 16:56:49 CDT 1995