Outline

• Finish Disk Failures
• RAID Levels
• Quiz
• Representing Records

Intermittent Failures

• Last week, we were talking about the memory hierarchy as it pertains to databases, and we were talking aboutt secondary storage, in particular, SSD and disk storage.
• We described four different kinds of disk failures: Intermittent failures, Media decay, Write Failures, and Disk crash.
• We now discuss each of these in more detail as well as how to mitigate againstt them.
• Disk sectors are usually stored with some extra bits that enable us to tell if the sector's content is correct or not on a read or a write.
• We model a disk read as returning a pair `(w,s)` where `w` is the data and `s` is the status as to whether the read was okay.
• In an intermittent failure, we may get several bad `s's` before a good one.
• Usually, we have some max tries (say 100) before we permanently fail.
• For write requests, after the write, we can do a read to see if the `s` is correct, and hence, if the write was successful.
• This read will typically take an additional disk revolution.
• If the write was not successful, we can repeat it.

Checksums

• What should we use for `s`?
  • A common thing to do is to take the parity of the bits in the sector for `s`. That is, `s` is 1 if the number of `1` bits in the sector is odd and `0` otherwise.
  • For example, if `w=0101100` then `s=1`. If `w=1111000` then `s=0`.

Stable Storage

• We want a policy in effect to be sure that, when we write to disk, we will get a sector which is correctly written, or that any data that was in the sector before the write can be safely recovered.
• This policy is called stable storage.

Implementing Stable Storage

• We pair sectors and each pair represents one-sector contents `X`.
• Call the two copies the left and right copies and denote them `X_L` and `X_R`.
• To write:
  • Write `X` into `X_L`. Check that `s` is good. If not repeat the write. If fail repeatedly, assume `X_L` corrupted and replace it with a different sector. Repeat this process for `X_R`.
• To read:
  • Try to read `X` from `X_L`. Check if `s` is good. If yes, then that is `X`, if not repeat. If fail repeatedly try to get the value from `X_R`.
• Above scheme works well for media and write failures.

Failure Model for Disks

• We now want to consider RAID (redundant arrays of independent disks) schemes that work well for disk crashes.
• The average time till a disk crash is called the mean time to failure (MTTF). For modern disk this is about 10 years.
• We model this by assuming roughly 10% of the disks fail in a given year.
• We want to use multiple disks to make the mean time to data loss to be a much bigger number than the MTTF.

Mirroring as a Redundancy Technique

• Suppose you have two disks with the same data.
• One is called the data disk and the other is the redundant disk.
• If a disk fails we replace it with a new disk and copy the data from the other disk that is still okay.
• What is the chance the second disk could fail during the replacement process?
  • If replacement takes 3 hours = `1/8` of a day = `1/2920` of a year, then the odds are `1/10 times 1/2920` or one in `29200` failures. The odds that one of the two disks fails in a given year is `2/10 = 1/5`. So MTTF for 2 disk is 5 years. So the mean time to data loss is `5 times 29200 = 146,000` years.
• Raid level 1 is to use mirroring.
• Raid level 0 is to use striping as described last day.
• Raid 2 and Raid 3 are rarely used. They combine either bit or byte level striping with either a Hamming code or parity bit for error detection.

Quiz

Which of the following statements is true?

1. Secondary storage and volatile memory are the same thing.
2. Resetting 0 to 1 on a SSD can be done at the bit level.
3. A disk controller is a small processor in an HDD capable of controlling the actuator arm that moves the head assembly on the disk.

Parity Blocks

• Mirroring is somewhat wasteful.
• RAID level 4 scheme assumes we have `n` data disks and one parity disk.
• The `i`th block of the parity disks consists of the parities of the data stored in the `i`th block of the other disks
• For example, if disk 1 block `i` had `1010` and disk2 block `i` had `1101` then a parity disk would have `0111`.
• To read in this set-up we don't bother with the parity disk.
• To write need to read old block and parity block. Then write new block and recalculate the parity.

RAID 4 and Failures

• If the parity disk crashes, we just replace it.
• If one disk fails then we can replace that disk and compute the value for each of its block based on the other disks and the parity blocks. For example, if

  Disk1blk1: 1001
  Disk2blk1: 1111
  Disk3blk1: ???? 
  ParityBlk1:0010
  

  Then Disk3blk1 must be:0100

RAID 5

• RAID 4 has a bottleneck whenever we need to do writes because we must also update the parity disk.
• Notice the rule of recovery for a parity disk is the same as for any other disk in RAID level 4.
• In RAID level 5 to reduce the bottleneck problem we change which disk is the parity disk depending on the block number.
• For instance, if have `n` disks then disk `j` is used as the parity disk for block `i` if `i mod n = j`.

RAID 6

• RAID 4 and 5 allow one to recover from single disk crashes.
• RAID 6 allows one to recover from multiple disk crashes.
• The idea is to divide the disks into some data disks and some redundant disks.
• We use the redundant disks to fill in the rest of a Hamming code word based on the data for that bit position in that block of the data disks.
• Such Hamming codes are error correcting and can correct for more than one disk errors.

Representing Data in Secondary Storage

How do we store relations and objects to disk?

• Attributes are stored as fixed or variable length sequences of bytes called fields.
• Fields in turn are organized into records which correspond to tuples or objects.
• Records need to be stored into disk blocks
• Finally, all the blocks used to store a relation or object are stored as a file.
• This might have additional structures associated with it such as indices.

Example

Consider trying to implement a record format for the table created by the following SQL statement:

CREATE TABLE MovieStar(
   name CHAR(30) PRIMARY KEY, 
   address VARCHAR(255),
   gender CHAR(1),
   birthdate DATE
);

• Our format needs to say:
  • How to convert CHAR, VARCHAR, etc to fields.
  • How to put the whole tuple into a record and then blocks, files, etc.
  • How to handle different sized records.
• We should also consider what happens when fields change in size

Representing Data Elements I

We now discuss how to represent various kinds of data elements:

• Fixed length strings - i.e., CHAR(n) fields for some fixed `n`.
  • To store these we just use an array of size n.
  • If a value has fewer than `n` bytes we use a special pad character.
  • For example, if we have type CHAR(5), a possible value cat might be stored as: cat**

Representing Data Elements II

• Variable-Length Character Strings - Suppose we had an attribute of type VARCHAR(n). Here `n` must be less than `255`. We could represent this in several different ways:
  • Length plus content. Allocate `n+1` bytes. Use the first byte for the length and the remaining bytes for the content. If leftover bytes ignore.
  • Null-terminated string. Allocate `n+1` bytes. Write string followed by a \0. Anything after the \0 is ignored.

Representing Data Elements III

• Date and Time - These are usually stored as a fixed length character string following some format. For example, might use format YYYY-MM-DD and have a value like "2005-02-07". Similarly, a time might have a format like HH:MM:SS.FF (SQL2) and have a value like "23:05:02.35". The .35 is the fraction of a second.

Representing Data Elements IV

• Bits - The SQL1999 and after type BINARY(n) is used when one wants sequences of `n` bits.
  • To store this we pack the bits into `|~ n/8 ~|` (round up) consecutive bytes.
  • Unused bits in last byte are ignored.
  • For example, suppose we want to store a BINARY(6) value `001100`. We might represent this with `00110000`.
  • Note sometimes store a single bit as `00000000` or `11111111`.
• Enumerated Types - {RED,GREEN,YELLOW}. These can be represented using numbers 0, 1, 2 and store in an integer.

Fixed-Length Records

• Let's take a first-pass at how a MovieStar tuple from our earlier CREATE TABLE could be stored:

  Record:	name	address	gender	birthdate
  Byte positions:	0	30	286	286	297

• Note this may be inefficient to process by 32 or 64 bit processors. Sometimes reorganize records so that each field divisible by 4 or 8 to help the processor.

Record Headers

Sometimes need to store addition info besides the value of each field. This data could be things like:

1. The record schema or a pointer to it.
2. The length of the record
3. Timestamp indicating when the data was last modified or read.

Schema Info

• When a CREATE TABLE is done the database stores:
  1. the attributes of the relation
  2. their types
  3. the order in which the attributes appear in the tuple
  4. any constraints on the attributes.
• This info is usually stored in the catalog/dictionary of the database.
• Each record then for a given relation keeps a pointer to where in the dictionary the information is stored.

MovieStar Record Layout Example

Packing Fixed-Length Records into Blocks

• A block might look like:

  header

  Rec `1`

  ...

  Rec `n`

• The header above is called a block header and might store:
  • Links to other blocks.
  • Role played by this block in network of blocks.
  • Info about which relation tuples in this block belong to
  • A directory giving offsets to records in this block
  • A block ID, and a timestamp for when this block was last read/modified.