200 likes | 345 Views
Database systems the complete book 13.6 . representing block and record addresses By Ahmad Yazdankhah ( ID 219) CS 257 P rof.: T. Y. Lin San José State University SPRING 2011. Overview. Database address space Virtual address space Map table Translation table Swizzling and UnSwizzling
E N D
Database systemsthe complete book13.6. representing block and record addresses ByAhmad Yazdankhah(ID 219)CS 257Prof.: T. Y. LinSan José State UniversitySPRING 2011
Overview • Database address space • Virtual address space • Map table • Translation table • Swizzling and UnSwizzling • Pinned Blocks
13.6.1. Addresses in Client-Server Systems • A database system is usually client-server architecture • The client applications use a conventional virtual address space • Server’s data is structured as database address space
13.6.1. (cont’d)The ways we represent addresses • Physical Address: each block and record has a physical address as: • Logical Address: each block can have a shorter address (4 bytes) as logical address. • A map table can translate logical-to-physical
13.6.1. (cont’d)Map table translates logical to physical Logical address Physical address
13.6.2. Logical and Structured Addresses • Why we use map table? • Answer: flexibility in data manipulation • How? • All pointers to the records refer to the map table • When moving records around or deleting, we can update the map table.
13.6.2. (cont’d) • How to combine physical and logical addresses? • With the physical address, reach the block and using the key value to find the record • Keep an offset table in the block header
13.6.2. (cont’d)Advantages • To move a record in a block, just change the offset table entry • To deletea record, just leave a tombstone in the offset table • To move to another block, just put the new block address in the offset table (forwardingaddress)
13.6.3. Pointer Swizzling • There are some cases that records contain pointers • When records represent objects(and not tuples) • Object-Relational databases • Index blocks (next chapter)
13.6.3. (cont’d)Swizzling • Here are some facts: • We know that all data manipulations are done in main memory. • To refer a data item on HD, we use database address space. • To refer a data item in memory, we use memory address.
13.6.3. (cont’d)Swizzling Question: what would happen to the pointers when we move the block from the secondary storage to memory?
13.6.3. (cont’d)Swizzling • So, we need a translation table to map this correspondence. Database Address Memory address
13.6.3. (cont’d)Swizzling • The techniques that change the pointer addresses is known as Pointer Swizzling. • The idea is that we should change the pointers content in order to point to the right locations.
13.6.3. (cont’d)1. Automatic Swizzling • When we move a block to memory, we put an entry for each pointer it has into the translation table.
13.6.3. (cont’d)2. Swizzling on demand • In this technique, we swizzle the pointers when we need them. • In this way we save the time because some records won’t be invoked at all.
13.6.3. (cont’d)3. No Swizzling • In this technique, we just create the translation table for the blocks and don’t swizzle the pointers inside the blocks. • It means that the pointers always use database address space.
13.6.4. Returning Blocks to Disk • Question: what would happen to the pointers when we move the block from memory to the secondary storage? • The pointers should be changed to database address space. This is called Unswizzling! • The translation table can be used in both direction.
13.6.5. Pinned Records and Blocks • If the block in the memory cannot be written back to the disk safely, we call it Pinned. • Example: Block B1 has a swizzled pointer to a record in Block B2. What would happen if we move the B2? • In this situation, we set the pin bit of B2 to prevent moving of B2.
13.6.5. (cont’d)To Unpin a Block • One possible approach is to keep track of all references to a block in a linked list.