Powered by ScribeFire.

    Data storage management is  the lowest  layer in the DBMS architecture.
    It consist of  2  main component:the  disk space manager(storage manager) and the buffer manager.

First of all, we must clarify 2 concepts: page and block.
    page is a logical concept while block is a physical concept which means the data unit  storing in disk.

Then, we ‘ll see the 2 component.

Storage manager(SM)
Responsibility:
- allocate/deallocate a page
- read/write a page

Problem we must solve:
- how to keep track of free block

Buffer manager(BM)
Responsibility:
- bring the requested page from the upper level to the  buffer pool

Problem we must solve:
- “Address Transformation”. How we can know which frame in the buffer pool the requested page corresponds to?
-
“Replacement Policies”.Which frame we should choose to replace if  the
buffer pool is full? And we must write the frame into disk is the 
frame  is  changed  after it brought into the buffer pool.
- “Concurrency Control”. What if a page is requested by several transactions.

Powered by ScribeFire.

General picture of where a DBMS sits:

What you’ll build in this class:

Closer look at DBMS, File System, and Disk:

Components of DBMS:

Missing from figure:

• Query results returned to User/Application
• Buffer Manager or Index/Record Managers call Concurrency Control
• Separate Table Manager
• Many, many (many!) details…

RedBase architecture:

Legend:

• PF: Paged File
• RM: Record Management
• IX: Indexing
• SM: System Management (DDL, utilities)
• QL: Query Language
• EX: Extension

Correspondence between RedBase and DBMS components:

• PF = Storage Manager + Buffer Manager
• RM = Record Manager
• IX = Index Manager
• SM = DDL Processor (+ misc. utilities)
• QL = Query Checker, Query Optimizer (simple), Execution Engine
• Command parser = Query Parser

Powered by ScribeFire.

Powered by ScribeFire.

团(clique):完全子图的顶点集

超图:G的“父图”

生成（Spanning）子图:顶点集＝V的子图

Powered by ScribeFire.

首先,用livecd进入系统.

$sudo -s #切换到root用户,一定要注意,否则后面一定会出问题
$grub #进入grub
grub> root (hd0,?) #按tab键会有很多候选项,选择根分区所在的disk
grub> setup (hd0) #安装grub到指定硬盘

一切顺利的话,这样就OK了.
要注意的地方是一定要切换到root用户,否则进入grub后会提示

error 21 : Selected disk does not exist

root (hd0,?) 的作用是设置根分区,
然后,
setup (hd0) 就会根据路径 “root/boot/grub”找到所需的文件

之后,遇到的一个问题就比较郁闷了.在grub在菜单中选择ubuntu提示

Error 15:File not found.

Google了一下,发现重装后有可能分区号会改变.
我原来的根分区为hda9,重装后变成了hda8:-(
对应grub就是由 (hd0,8) 变为 (hd0,7)
修改/boot/grub/menu.lst中的相应项得以解决

Powered by ScribeFire.

它的核心思想实际上很简单，就是将程序也用存储器存储下来(所谓以存储器为中心)，CPU与存储程序的存储器是分开的。

wikipedia上的解释是这样的(wiki真是我们这个时代最伟大的发明之一，由于某些原因有时候无法正常访问，你可以通过answers.com来间接访问它)

Design of the Von Neumann architecture

The von Neumann architecture is a computer design model that uses a single storage structure to hold both instructions and data, named after mathematician and early computer scientist John von Neumann. The term describes such a computer, which implements a Universal Turing machine, and the common “referential model” of specifying sequential architectures, in contrast with parallel architectures.

The separation of storage from the processing unit is implicit in the von Neumann architecture. The term “stored-program computer” is generally used to mean a computer of this design.

也就是说，von Neumann体系结构是用一个单独的存储器来存储程序和数据的(a single storage structure to hold both instructions and data)，因此他也被称为”stored-program computer”，而之前早期的computing machines程序是固定的。
数据与程序是存储在一起的，计算机通过不同的阶段来区分数据与程序。在取址阶段取出数据，在执行阶段取出的则是数据。

von Neumann的体系结构在开始设计时，甚至可以让程序在运行是改变自身。这样设计的最初动机是为了在必要的时候改变代码的地址部分，在有了 index registers and indirect addressing之后这样做就显得没多少吸引力，它带来的问题远比利益来的多。

von Neumann体系结构带来的瓶颈也很明显的：程序与CPU的分离使CPU与memory间的throughput (data transfer rate)成为最主要的瓶颈。

The separation between the CPU and memory leads to the von Neumann bottleneck, the limited throughput (data transfer rate) between the CPU and memory in comparison with the amount of memory.

“Keep it simple”是一种非常有用的方法。隐藏在复杂的方法，繁琐的细节背后的想法往往是极其简单的，也正因此才显出优美。看问题就应该如此。