标签归档:数据字典

MYSQL小白的FAQ系列—-6—-如何查看mysql中的“元数据”(类似于oracle的数据字典)

mysql中,INFORMATION_SCHEMA提供了访问数据库元数据的方式. 元数据是关于数据的数据,如数据库名或表名,列的数据类型,或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。 在mysql5.5的官方文档中有以下内容: 第23章:INFORMATION_SCHEMA信息数据库 目录 23.1. INFORMATION_SCHEMA表 23.1.1. INFORMATION_SCHEMA SCHEMATA表 23.1.2. INFORMATION_SCHEMA TABLES表 23.1.3. INFORMATION_SCHEMA COLUMNS表 23.1.4. INFORMATION_SCHEMA STATISTICS表 23.1.5. INFORMATION_SCHEMA USER_PRIVILEGES表 23.1.6. INFORMATION_SCHEMA SCHEMA_PRIVILEGES表 23.1.7. INFORMATION_SCHEMA TABLE_PRIVILEGES表 23.1.8. INFORMATION_SCHEMA COLUMN_PRIVILEGES表 23.1.9. INFORMATION_SCHEMA CHARACTER_SETS表 23.1.10. INFORMATION_SCHEMA COLLATIONS表 23.1.11. INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY表 … 继续阅读

发表在 FAQ | 标签为 , , | 留下评论

研究数据字典和基表,发现处理手工删除fs$或者file$等问题的新思路

在测试环境玩什么东西忘记了,反正是忽然发现有个没用的表空间“UNDOTBS1”删除不掉,以前写过一篇,如何查找某个对象的定义(V$_X$_DBA), 这里重温一下数据字典和动态性能视图: UNDOTBS1在v$tablespace中可见,但是不能drop,在dba_tablespaces中不可见,说明数据字典和动态性能视图不匹配了(手工删除了基表导致的,忘记是删除了ts$还是file$内容了): 不得不说Oracle 11.2.0.3以后的版本,对于数据库的一致性校验进行了很人性化的改动,以前这种情况是crash的,现在还open着,带病工作,O(∩_∩)O哈哈~ 类似的带病工作的情况,还涉及到很多数据字典的不一致情况,比如以前的i_dependency1, i_dependency2等等。 从这个研究,也证实了如下结论: V$TABLESPACE的信息是来源于GV$TABLESPACE,GV$TABLESPACE来源于基表 X$KCCTS 而DBA_TABLESPACES是来源于 SYS.TS$ TS 和 SYS.X$KCFISTSA。也就是说,V$TABLESPACE的信息来源于控制文件,而DBA_TABLESPACES的信息是来源于其他基表,手工删除基表信息时,其信息不和控制文件信息同步。 下面有具体看看: 看下创建动态性能视图的语句: 通过上面建库脚本也可以清晰的看到,得到授权的普通用户仍然只能访问V$开头的视图,而不能直接访问V_$开头的视图,因为实际上V$视图是V_$视图的公有同义词(PUBLIC SYNONYM)要想访问V_$必须带上SYS.V_$,例如 而查看普通的DBA_ ALL_ USER_ 等视图,可以查看数据字典 dba_views(这个视图从8i开始引入的) 例如: X$ 是 Oracle 数据库 的核心部分,这些表用于跟踪内部数据库信息,维护数据库的正常运行。 X$ 表是加密的(除了MOS和直接看源代码以外,我不知道还有什么方法可以查看X$视图) Oracle 通过 X$和一些基表(TS$, OBJ$, SEG$等)建立起其他大量视图,提供用户查询和管理数据库。 在9i以前 另外,还可以通过X$KQFTA来查看X$表的相关信息: 类似,就是11.2中新引入的X$表: … 继续阅读

发表在 FAQ, Internal | 标签为 , , , , | 留下评论