Silberschatz Korth Sudarshan: Database System Concepts, Fourth Edition in Software

Encoder Code 128 Code Set A in Software Silberschatz Korth Sudarshan: Database System Concepts, Fourth Edition

The McGraw Hill Companies, 2001

11

519568501200 519568501200

Suppose that an object has to be moved to a new block, perhaps because the size of the object has increased, and the old block has no extra space Then, the physical OID will point to the old block, which no longer contains the object Rather than change the OID of the object (which involves changing every object that points to this one), we leave behind a forwarding address at the old location When the database tries to locate the object, it nds the forwarding address instead of the object; it then uses the forwarding address to locate the object

We implement persistent pointers in a persistent programming language by using OIDs In some implementations, persistent pointers are physical OIDs; in others, they are logical OIDs An important difference between persistent pointers and in-memory pointers is the size of the pointer In-memory pointers need to be only big enough to address all virtual memory On most current computers, in-memory pointers are usually 4 bytes long, which is suf cient to address 4 gigabytes of memory The most recent computer architectures have pointers that are 8 bytes long, Persistent pointers need to address all the data in a database Since database systems are often bigger than 4 gigabytes, persistent pointers are usually at least 8 bytes long Many object-oriented databases also provide unique identi ers in persistent pointers, to catch dangling references This feature further increases the size of persistent pointers Thus, persistent pointers may be substantially longer than in-memory pointers The action of looking up an object, given its identi er, is called dereferencing Given an in-memory pointer (as in C++), looking up the object is merely a memory reference Given a persistent pointer, dereferencing an object has an extra step nding the actual location of the object in memory by looking up the persistent pointer in a table If the object is not already in memory, it has to be loaded from disk We can implement the table lookup fairly ef ciently by using a hash table data structure, but the lookup is still slow compared to a pointer dereference, even if the object is already in memory

The McGraw Hill Companies, 2001

Pointer swizzling is a way to cut down the cost of locating persistent objects that are already present in memory The idea is that, when a persistent pointer is rst dereferenced, the system locates the object and brings it into memory if it is not already there Now the system carries out an extra step it stores an in-memory pointer to the object in place of the persistent pointer The next time that the same persistent pointer is dereferenced, the in-memory location can be read out directly, so the costs of locating the object are avoided (When persistent objects have to be moved from memory back to disk to make space for other persistent objects, the system must carry out an extra step to ensure that the object is still in memory Correspondingly, when an object is written out, any persistent pointers that it contained and that were swizzled have to be deswizzled, that is, converted back to their persistent representation Pointer swizzling on pointer dereference, as described here, is called software swizzling Buffer management is more complicated if pointer swizzling is used, since the physical location of an object must not change once that object is brought into the buffer One way to ensure that it will not change is to pin pages containing swizzled objects in the buffer pool, so that they are never replaced until the program that performed the swizzling has nished execution See the bibliographical notes for more complex buffer-management schemes, based on virtual-memory mapping techniques, that make it unnecessary to pin the buffer pages