数据字典视图及其用途（ORACLE数据库）求助各位大神，！

数据字典

是元数据的集合，从逻辑上和物理上描述了数据库及内容，存储于SYSTEM与SYSAUX表空间内的若干段。

SYS用户拥有所有的数据字典表，数据字典基本一般以$结尾，如col$，tab$等，这些数据字典存放在system表空间中。

数据字典的形成

在数据库创建阶段创建，在使用阶段维护和更新

无法通过DML操作来修改，只能通过相关的命令修改系统，来达到间接修改数据字典。

数据字典的特点

每个Oracle数据库的中枢

描述数据库和它的对象

包含只读的表和视图

存储在SYSTEM表空间中

拥有者是SYS用户

由Oracle服务器自己维护

用SELECT访问

数据字典内容:

数据字典提供下列信息:

逻辑和物理的数据库结构

对象的定义和空间分配

一致性限制

用户

角色

权限

审计

数据字典的主要用途：

Oracle服务器用它查找下列信息：

用户

对象

存储结构

Oracle服务器修改数据字典当DDL语句执行的时候

用户和管理员们利用它了解数据库的信息

基础表和数据字典视图：

数据字典包括两个部分:

基础表

存储数据库的描述

CREATE DATABASE命令创建（sqlbsq)

数据字典视图

用于简化基础表的信息

通过PUBLIC同义词访问

由脚本catalogsql创建

数据字典基表中的数据很难看懂。因此，很少人直接访问这些基表。取而代之的是数据字典视图。

数据字典视图分为类，它们以前辍来区分，前辍分别为：USER、ALL、DBA

USER_ 用户所拥有的对象信息

ALL_ 用户能访问的对象信息

DBA_ 整个数据库中的对象信息

创建数据字典视图：

建库后，运行以下脚本创建的

$ORACLE_HOME/rdbms/admin/catalogsql 创建常用的数据字典和同义词

$ORACLE_HOME/rdbms/admin/catprocsql 创建内建的存储过程、包等pl/sql对象

DBCA建库时会自动运行这两个脚本，但如果手动建库的话，需手动运行。

常用的数据字典：

一般的概况: TAB，DICTIONARY, DICT_COLUMNS

对象: DBA_TABLES, DBA_INDEXES, DBA_TAB_COLUMNS, DBA_CONSTRAINTS --->user_ ,all_

空间分配: DBA_SEGMENTS, DBA_EXTENTS

数据库结构: DBA_TABLESPACES, DBA_DATA_FILES

动态性能视图:

是将内存里的数据或控制文件里的数据以表的形式展现出来，它们实际都是虚拟表，并不是真正的表

只要数据库在运行，就会不断更新动态性能视图

一旦数据库关闭或崩溃，则动态性能视图里的数据就丢失，当数据库重新启动后，数据将会被更新

所有的动态性能视图名称都存放在v$fixed_table里。这些动态性能视图都是以V_$开头，属主是sys

oracle为每个动态性能视图都创建了同义词，同义词将中间的“_”去掉了，形成以v$开头

常用的数据字典视图、动态性能视图：

dba_objects

dba_tables

dba_users

dba_tablespaces

V$CONTROLFILE 控制文件信息

V$DATABASE 数据库信息

V$DATAFILE 数据文件信息

V$INSTANCE 实例信息

V$PARAMETER 参数信息

V$SESSION 会话信息

V$SGA SGA信息

V$SGAINFO SGA信息

V$TABLESPACE 表空间信息

V$THREAD

V$VERSION

V$option

v$parameter显示的是session级的参数，也就是当前session的参数信息。

如果没有使用alter session单独设置当前session的参数值，那么默认和system级的参数应该是一样的。

v$system_parameter显示的是system级的参数，保存的是使用alter system修改的值（scope=both或者scope=memory）。

上面两个都是当前已经生效的参数值。对于使用spfile的库，也可以暂时只修改spfile中的

值。v$spparameter显示的就是保存在spfile中的参数值（scope=spfile）。

扩展或收缩哈希表需要将ht[0]中的所有键值对rehash到ht[1]中。不过，这个rehash的动作不一定是一次性、集中式完成的，而是分多次、渐进式完成的。

这样做的原因在于，避免当ht[0]中保存了太多的键值对时，一次性集中式rehash让服务器在较长的时间内停止服务。rehash动作的过程中肯定是不能对外提供增删改查的操作的，如果ht[0]中只有四个键值对的话，那么一次性完成rehash也不会对服务器的运行造成太多延迟，但如果是四百万、四千万的话一次性完成rehash将会严重阻塞服务器运行。

以下是哈希表渐进式rehash的详细步骤：

渐进式 rehash 采用了 分治 的思想，将 rehash 键值对所需的工作分摊到了每次对字典的增删改查操作上，虽然降低了 redis 服务器的整体吞吐量，但提升了响应速度，不会出现在某次操作时特别慢的情况。

因为在渐进式 rehash 的过程中，字典会同时使用 ht[0] 和 ht[1] 两个哈希表，所以在这个过程中对字典的增删改查操作会在两个哈希表上进行。例如在字典上查找一个键时，程序会先查询ht[0]，如果没有查到就再查 ht[1]。

新添加到字典上的键值对只会保存在ht[1]上，而ht[0]上不再进行任何添加操作，这样就保证了ht[0]中包含的键值对的数量只减不增，并随着rehash的进行而逐渐变成空表。

HTTP有两个主要的缺点:安全不足和性能不高。

HTTPS，通过引入SSL/TLS在安全上达到了“极致”，但在性能提升方面却是乏善 可陈，只优化了握手加密的环节，对于整体的数据传输没有提出更好的改进方案，还只能依赖于“⻓连 接”这种“落后”的技术。Google率先发明了SPDY协议，并应用于 自家的浏览器Chrome，打响了HTTP性能优化的“第一枪”。随后互联网标准化组织IETF以SPDY为基础，综合其他多方的意⻅，终于推出了HTTP/1的继任者，也就是今 天的主⻆“HTTP/2”，在性能方面有了一个大的⻜跃。

由于HTTPS已经在安全方面做的非常好了，所以HTTP/2的唯一目标就是改进性能。但它不仅背负着众多的期待，同时还背负着HTTP/1庞大的历史包袱，所以协议的修改必须小心谨慎，兼容 性是首要考虑的目标，否则就会破坏互联网上无数现有的资产。因为必须要保持功能上的兼容，所以HTTP/2把HTTP分解成了“语义”和“语法”两个部分，“语义”层不 做改动，与HTTP/1完全一致(即RFC7231)。比如请求方法、URI、状态码、头字段等概念都保留不变，这 样就消除了再学习的成本，基于HTTP的上层应用也不需要做任何修改，可以无缝转换到HTTP/2。特别要说的是，与HTTPS不同，HTTP/2没有在URI里引入新的协议名，仍用“http”表示明文协议， 用“https”表示加密协议。

首先，HTTP/2对报文的头部做了一个“大手术”。HTTP/1里可以用头字段“Content-Encoding”指定Body的编码方式，比如用gzip压缩来节约带宽，但报文的另一个组成部分⸺Header却被无视了，没有针对它的优化手段。

由于报文Header一般会携带“User Agent”“Cookie”“Accept”“Server”等许多固定的头字段，多达 几百字节甚至上千字节，但Body却经常只有几十字节(比如GET请求、204/301/304响应)，成了不折不扣 的“大头儿子”。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费，“⻓尾效 应”导致大量带宽消耗在了这些冗余度极高的数据上。所以，HTTP/2把“ 头部压缩 ”作为性能改进的一个重点，优化的方式你也肯定能想到，还是“压缩”。

不过HTTP/2并没有使用传统的压缩算法，而是开发了专⻔的“ HPACK ”算法，在客户端和服务器两端建立“字典”， 用索引号表示重复的字符串 ，还釆用哈夫曼编码来压缩整数和字符串，可以 达到50%~90%的高压缩率 。

你可能已经很习惯于HTTP/1里纯文本形式的报文了，它的优点是“一目了然”，用最简单的工具就可以开 发调试，非常方便。但HTTP/2在这方面没有“妥协”，决定改变延续了十多年的现状，不再使用肉眼可⻅的ASCII码，而是向下层的TCP/IP协议“靠拢”， 全面采用二进制格式 。这样虽然对人不友好，但却大大方便了计算机的解析。原来使用纯文本的时候容易出现多义性，比如大小 写、空白字符、回⻋换行、多字少字等等，程序在处理时必须用复杂的状态机，效率低，还麻烦。

它把TCP协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”(Frame)，用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。这种做法有点像是“Chunked”分块编码的方式。也是“化整为零”的思路，但HTTP/2数 据分帧后“Header+Body”的报文结构就完全消失了，协议看到的只是一个个的“碎片”。

消息的“碎片”到达目的地后应该怎么组装起来呢HTTP/2为此定义了一个“ 流”(Stream) 的概念，它是 二进制帧的双向传输序列 ，同一个消息往返的帧会分配一个唯一的 流ID 。你可以想象把它成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是HTTP/1里的请求报文和响应报文。

因为“流”是 虚拟 的，实际上并不存在，所以HTTP/2就可以在一个TCP连接上 用“流”同时发送多个“碎片化”的消息 ，这就是常说的“ 多路复用 ”( Multiplexing)⸺多个往返通信都复用一个连接来处理。在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发 的“帧”。多个请求/响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降 低了延迟，大幅度提高了连接的利用率。

为了更好地利用连接，加大吞吐量，HTTP/2还添加了一些 控制帧 来管理虚拟的“流”，实现了 优先级和流量控制 ，这些特性也和TCP协议非常相似。

HTTP/2还在一定程度上改变了传统的“请求-应答”工作模式，服务器不再是完全被动地响应请求，也可以 新建“流”主动向客户端发送消息 。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文 件发给客户端，减少等待的延迟，这被称为“ 服务器推送 ”(Server Push，也叫Cache Push)。

出于兼容的考虑，HTTP/2延续了HTTP/1的“明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密。但由于HTTPS已经是大势所趋，而且主流的浏览器Chrome、Firefox等都公开宣布只支持加密的HTTP/2， 所以“事实上”的HTTP/2是加密的。也就是说， 互联网上通常所能⻅到的HTTP/2都是使用“https”协议 名，跑在TLS上面 。为了区分“加密”和“明文”这两个不同的版本，HTTP/2协议定义了两个字符串标识符:“h2”表示加密的HTTP/2，“h2c”表示明文的HTTP/2，多出的那个字母“c”的意思是“clear text”。

在HTTP/2标准制定的时候(2015年)已经发现了很多SSL/TLS的弱点，而新的TLS13还未发布，所以加密 版本的HTTP/2在安全方面做了强化，要求下层的通信协议必须是TLS12以上，还要支持前向安全和SNI，并 且把几百个弱密码套件列入了“黑名单”，比如DES、RC4、CBC、SHA-1都不能在HTTP/2里使用，相当于 底层用的是“TLS125”。

redis哨兵和集群区别是：

监控主数据库和从数据库是否正常运行。

主数据库出现故障时自动将从数据库转换为主数据库。sentinel发现master挂了后，就会从slave中重新选举一个master。哨兵模式强调高可用。

Sentinel会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作。

它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器。

当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

客户端中不会记录redis的地址（某个IP），而是记录sentinel的地址，这样我们可以直接从sentinel获取的redis地址。

因为sentinel会对所有的master、slave进行监控，它是知道到底谁才是真正的master的，例如我们故障转移，这时候对于sentinel来说，master是变了的，然后通知客户端。

而客户端根本不用关心到底谁才是真正的master，只关心sentinel告知的master。

集群即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。

为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容，共有16384个slot。

每个redis分得一些slot，hash_slot = crc16(key) mod 16384找到对应slot，键是可用键，如果有｛｝则取｛｝内的作为可用键，否则整个键是可用键。

集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。

集群模式提高并发量。

Redis：Remote Dictionary Server ，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。