Oracle数据库的管理

安全的实现 在多用户环境中 有效管理Oracle数据库最重要的方面就是创建一个安全模式来控制对数据库的访问和更改 在一个Oracle中 可以对单独的用户或数据库角色授予安全许可 安全管理一般在 个级别中执行 ·数据库级· *** 作系统级·网络安全级 用户名 权限 组和角色 DBA或数据库安全管理员创建用户名（username）来提供有效的用户标识符 用来和数据库连接 在安装过程中自动创建两个赋予DBA角色的用户账号 SYS和SYSTEM 角色（role）是权限的命名组 可以被创建 更改或删除 在大多数实现中 DBA或安全管理员为用户创建用户名并分配角色 从而赋予用户一个权限集 每个数据库都有个伪角色 称为PUBLIC 它包含所有的拥护 所有的用户都可以赋予PUBLIC权限 如果通过关键字PUBLIC创建了数据库链接 那么对于所有用户这些链接都是可见的 安全权限 有 个基本的安全权限可适用于Oracle数据库中的数据 ·SELECT 执行查询·INSERT 在表或视图中插入行·UPDATE 更新表或视图中的行·DELETE 从表 表分区或视图中删除行除了这些数据特定的权限外 还有以下用于数据库模式中对象的权限 ·CREATE 在模式中创建表·DROP 在模式中删除表·ALTER 更改表或视图所有权限都是通过两个SQL命令来处理 GRANT命令把一个特定的权限赋予一个用户或角色 REVOKE命令用于取消某个特定的权限其中任何一个命令都可以结合关键字PUBLIC对所有的用户赋予或取消某个权限 默认角色和权限 默认角色和权限集是Oracle安装过程中预先定义的每个版本的默认角色都有所变化CONNECT可用于注册登录到数据库 创建对象和执行导出 RESOURCE可用于创建过程 触发器 以及用户模式区内的类型 DBA赋予无限制的权限 SYSOPER权限集 允许远程地建立与数据库的连接 并执行有限的已授权的 *** 作 包括启动和关闭 SYSDBA权限集 和DBA角色十分相近 包含了SYSOPER权限集以及ADMIN OPTION所有的权限 可用于与远程数据库连接 并远程执行已授权的 *** 作 如关闭或启动数据库 EXP_FULL_DATABASE允许执行任何数据库对象导出 *** 作 并且将导出 *** 作记录在数据字典中 IMP_FULL_DATABASE可用于成为数据库的用户 这样用户的对象就可以导入适当的模式内 DELETE_CATALOG_ROLE可用于从SYS AUD$审计表中删除行 EXECUTE_CATALOG_ROLE可用于执行恢复目录中列出的所有导出包 SELECT_CATALOG_ROLE可用于从所有导出恢复目录视图和表中选择角色 RECOVERY_CATALOG_OWNER可用于创建恢复目录的所有者 SNMPAGENT可用于Oracle企业智能代理 DBA角色STARTUP启动一个数据库实例 SHUTDOWN关闭数据库实例 ALTER DATABASE OPEN打开一个已安装的但是关闭的数据库 ALTER DATABASE MOUNT通过前面的启动实例来安装一个数据库 ALTER DATABASE BACKUP例如 启动一个控制文件的备份 但是现在用的大多是通过RMAN来备份ALTER DATABASE ARCHIVELOG指定在日志文件组可以重用之前 日志文件组的内容必须归档 ALTER DATABASE RECOVER逐个地应用日志或启动日志文件的自动化应用 CREATE DATABASE创建并命名一个数据库 指定数据文件和大小 并指定日志文件及其大小 还要设置参数限制RESTRICTED SESSION可用于与受限（Restricted）模式中启动的数据库相连接 设计受限模式的目的是使用户避免进行某些数据库 *** 作DBA角色的权限一般用于对用户分配表空间配额 设置系统资源限制以及建立审计 安全审计 lishixinzhi/Article/program/Oracle/201311/16942

ORACLE数据库中 表是最基本的内容 可以说 表设计的好坏直接跟数据库的性能相关 所以 在设计表的时候 除了要遵循其固有的数据库准则之外 还需要看个人的数据库管理经验 下面我就把这些经验分享一下 或许对大家有所帮助 一 表该存放在哪里 我们都知道 在ORACLE数据库中 使利用空间这个概念来管理表对象的 在数据库创建的时候 数据库中已经建立了一些表空间 那么当我们新建立表的时候 这个新表的位置该放在什么地方呢这就好像吃饭时的坐的位置一样 是有讲究的 一般来说 我们在新建表的时候 至少要遵循如下建议 一是在数据库创建的时候 在数据库中已经有了一个SYSTEM的表空间 一般情况下 这个表空间中 只包含数据字典及Oracle系统对象 如果我们将我们的表建立在这个空间上的话 那是要降低数据库的性能的 所以 一般我们是不建议用户把表格建立在这个空间上 但是 若我们不只一个人维护数据库 如有八个人共同设计数据库系统时 如何才能保证其他用户不在SYSTEM表空间中建立数据库表格呢最好的办法就是通过权限控制 如我们可以给每个数据库设计人员指定一个默认的表空间 让他们只能在这个表空间中建立表格 如此的话 就能防止他们在SYSTEM表空间中建立自己的数据表格 从而对数据库的运行性能产生不良影响 所以 若给每个用户设置默认表空间的话 那么用户在建立具体的表时 不用具体指定表空间了 二是我们在为某个应用设计数据库的时候 最好先对表的空间进行规划 一般情况下 不要把数据表随意的分散到不同的表空间中去 如我们在为一个ERP系统设计数据库的时候 若把采购部门相关的表跟销售部门相关的表放到两个不同的表空间中去 这是不明智的做法 这么处理的话 会降低某些数据库管理和维护 *** 作的效率 如数据的备份与恢复 *** 作;而且 也无法集中管理属于某个特定应用的数据 所以 我们一般建议 在规划数据库表空间的时候 把相同应用的表放在同一个表空间中去 如果要区分不同部门或者不同模块的表的话 我们可以在表的命名上动脑子 如我们在设计ERP系统的数据库中 可以根据其应用模块的不同 在前面加上前缀来进行识别 如跟系统基本配置相关的表 我们可以用AD为前缀;而跟销售部门相关的表 我们可以加上SA前缀等等 如此的话 这些表具体是属于哪个模块的 就一清二楚了 完全没有必要为此设置不同的表空间 这是ORACLE数据库初学者经常会犯的错误 主要是对ORACLE表空间的定义不是很熟悉所导致的 二 对预计存储数量比较大的表时 要给与额外的重视 有些表非常的大 我们这边说的大 不一定是说结构复杂 而是指在这个表格中 预期会存储比较多的数据 为了提高对这个表格的处理效率 我们在事先要做出一定的安排 否则的话 后续对这些大表进行查询 插入等 *** 作的话 速度会很慢 所以 我们就有必要在数据库设计的时候 先预先估计一下表的数据存储量 把一些数据量大的表格 做一些额外的设置 如在ERP软件的数据库设置中 一般来说 产品数据与物料清单数据这两个表的数据量会比较大;而从长远看的话 销售订单 采购订单 生产订单 记账凭证等这种单据类相关的表格其数据量也会比较大 一年两年可能感觉不出来 但是 到十年后 这个纪录数量就会很庞大 而像ERP系统这种大型的信息化管理项目 用个几十年时很正常的事情 而且 为了记录的完整性 也不建议用户把以前的数据删除 所以 为这种应用进行数据库设计的时候 要充分考虑这些大表的性能问题 具体的来说 设计大表的时候 可以考虑遵循如下的建议 一是不要为大表设置存储的限制 在ORACLE数据库中 可以为每张表格设置存储配额限制 如此的话 表最大容量就不能超过这个限制 对于一些数据容量比较小的表格 这么设置时合理的 可以提高空间的利用率 但是 若数据量比较大的话 就不建议事先设置表的存储空间了 如ERP系统的销售订单表 其刚开始可能记录量很小 第一年预计只有 G的记录容量 但是 估计在十年后 这个记录容量就会达到 G了 在这种情况下 我们怎么来给其设置存储空间呢一开就设置 G空间 这也是不合理的 而且 设置存储空间 就意味着有可能产生存储碎片 从而影响到数据查询的效率 所以 在数据库表的设计过程中 若某些应用的表可能会有比较大的数据容量时 建议不要对其存储空间做出任何的限制 二是要为这大表分配足够的临时空间 如我们使用ERP系统时 要查询产品资料信息 我们都知道 产品信息的话 有些企业这个纪录数非常的庞大 而且在查询时 我们还会经常的进行排序 *** 作 如有时候会按照产品编码对查询出来的数据进行排序 当记录少的话 还好;但是 当记录多的话 这个排序动作 要求具有比较大的临时存储空间 所以 当某个表预计会有很大的记录数量的时候 我们就要给其分配足够多的临时空间 临时空间的存储参数设置取决于临时表空间的默认储存参数设置 我们可以更改这些参数 以达到我们对要求 若没有给大表分配足够多的临时空间的话 则排序的动作将会很慢 而且很可能不成功 三是要考虑将表与表的索引分离存放 大表所对应的索引通常也比较大 一般来说 索引的数量是随着表记录的数量增加而增加 两者是接近于一个正比例的关系 所以 通常表的记录容量大的时候 索引数量也会很庞大 针对这种情况 我们考虑突破我们上面讲的表空间的规则定义 而考虑把表和他的索引分别存储于不同的表空间中 甚至在条件允许的情况下 分别存储于不同的硬盘中 这么做的好处是什么呢最大的好处是让索引比较容易的获得所需要的连续的存储空间 从而提高输入输入的效率 通俗的说 就是可以提高数据的查询效率 如不这么处理的话 查询大容量的记录的话 数据库可能需要花费 秒;而如此设计的话 就可能把时间缩短为 秒 这是一个很明显的性能改善 三 如何给表命名 上面我在讲如何为表分配存储空间的时候 已经讲到过这方面的问题 下面 我就将对这个问题进行详细的描述 以帮助数据库管理员掌握一套好的数据库命名规则 首先 毋庸置疑的 在为标命名的时候 要遵循ORACLE数据库的基本命名规则 如不能以数字开头为表命名 如不能利用数据库的关键字为表命名 如表的名字不能重复等等 这些是最基本的要求 就不用我多费口舌了 除了要遵循这些基本的命名规则外 在实际工作中 为了数据库后续的维护等方面出发 我们还是要遵循一些额外的规则 这些规则跟ORACLE定义的规则不同 我们所讲的规则没有约束力 可以说 只是业界的一些共识而已 你若不怎么处理 ORACLE数据库也不会说你错误 只是后续维护的时候 会比较麻烦而已 一是在对数据库命名的时候 最好能跟体现表的分类关系 如最常见的 我们在设计数据库的时候 表都是按系统的具体模块来区分的 如根据前端系统要求的不同 数据库的表大致可以分为系统基本配置表 销售模块表 采购模块表 报表模块表等等 我们可以根据这些模块的不同 分别给与不同的前缀来区分 这么做的好处是很明显的 如一看到表最大名字 就可以知道这个表是属于哪个应用的 哪个模块的 这无疑可以提高数据库设计与前台软件开发的效率 同时 数据库中默认的排序规则是按名字来排序的 所以 为表格设置类别前缀的话 可以把同一类的表格排在一起 方便我们察看 二是对表格命名的时候 要考虑可读性 而不能随便阿狗阿猫的乱取名字 最常见的是 那些刚学数据库的人 在表命名的时候 如要建几张测试表 就会随便命名如TEST TEST 之类的 虽然这只是测试 但是 也不符合我们的命名过则 要做测试的话 那就以TEST开头 然后后面加上具体要测试的内容 如此的话 我们才可以通过表的名字知道该表具体的用途 而不用打开表去看里面具体的结构或者注释才能知道我们需要的信息 所以 在设计表的名字的时候 还要关注一下其的可读性 lishixinzhi/Article/program/Oracle/201311/18317

oraclecount一直出不来数量的原因和优化方法有索引问题、数据库性能问题、数据库锁问题、数据库版本问题。

1、索引问题：如果查询条件中的字段没有建立索引，或者索引失效，可能会导致oraclecount查询速度变慢，甚至无法返回结果。此时，可以通过建立索引或者优化查询语句来解决问题。

2、数据库性能问题：如果数据库的性能较差，例如内存不足、CPU占用率过高等，也可能导致oraclecount查询缓慢或者无法返回结果。此时，可以通过优化数据库配置或者增加服务器硬件资源来提升数据库性能。

3、数据库锁问题：如果在查询时出现了锁表或者锁行的情况，也会导致oraclecount无法返回结果。此时，可以通过查看数据库锁的情况，或者优化并发访问控制来解决问题。

4、数据库版本问题：如果使用的Oracle数据库版本较老，可能存在一些已知的Bug或者性能问题，需要升级到较新的版本来解决问题。

在SQLPlus中用insert 的都是中文的 为什么一存入服务器后 再select出的就是 有的时候 服务器数据先导出 重装服务器 再导入数据 结果 发生数据查询成 …… 这些问题 一般是因为字符集设置不对造成的 很久以来 字符集一直是困扰著众多Oracle爱好者的问题 笔者从事Oracle数据库管理和应用已经几年了 经常接到客户的类似上面提到的有关数据库字符集的 告急 和 求救 在此我们就这个问题做一些分析和探讨 首先 我们要明确什么是字符集？字符集是一个字节数据的解释的符号集合 有大小之分 有相互的包括关系 如us ascii就是zhs gbk的子集 从us ascii到zhs gbk不会有数据解释上的问题 不会有数据丢失 Oracle对这种问题也要求从子集到超集的导出受支持 反之不行 在所有的字符集中utf 应该是最大 因为它基于unicode 双字节保存字符(也因此在存储空间上占用更多) 其次 一旦数据库创建后 数据库的字符集是不能改变的 因此 在设计和安装之初考虑使用哪一种字符集是十分重要的 数据库字符集应该是 *** 作系统本地字符集的一个超集 存取数据库的客户使用的字符集将决定选择哪一个超集 即数据库字符集应该是所有客户字符集的超集 在实际应用中 和字符集问题关系最大的恐怕就是exp/imp了 在做exp/imp时 如果Client 和Server的nls_lang设置是一样的 一般就没有问题的 但是 要在两个不同字符集的系统之间导数据就经常会有这样或那样的问题 如 导出时数据库的显示正常 是中文 当导入到其他系统时 就成了乱码 这也是一类常见问题 现在 介绍一些与字符集有关的NLS_LANG参数 NLS_LANG格式 NLS_LANG = language_territory charset 有三个组成部分（语言 地域和字符集） 每个成分控制了NLS子集的特性 其中 language 指定服务器消息的语言 territory 指定服务器的日期和数字格式 charset 指定字符集 例如 AMERICAN_AMERICA US SCII AMERICAN _ AMERICA ZHS GBK 还有一些子集可以更明确定义NLS_LANG参数 DICT BASE 数据字典基本 表版本 DBTIMEZONE 数据库时区 NLS_LANGUAGE 语言 NLS_TERRITORY 地域 NLS_CURRENCY 本地货币字符 NLS_ISO_CURRENCY ISO货币字符 NLS_NUMERIC_CHARACTERS 小数字符和组 分隔开 NLS_CHARACTERSET 字符集 NLS_CALENDAR 日历系统 NLS_DATE_FORMAT 缺省的日期格式 NLS_DATE_LANGUAGE 缺省的日期语言 NLS_SORT 字符排序序列 NLS_TIME_FORMAT 时间格式 NLS_TIMESTAMP_FORMAT 时间戳格式 …… 通过props$动态性能视图 我们可以查看数据库的字符集信息 $> sqlplus internal SQL> desc props$ Name Type Nullable Default Comments NAME VARCHAR ( ) VALUE$ VARCHAR ( ) Y MENT$ VARCHAR ( ) Y SQL> set arraysize SQL> col value$ format a SQL> select name value$ from props$ where name= NLS_CHARACTERSET ; NAME VALUE$ NLS_CHARACTERSET ZHS GBK SQL> select from sys props$; NAME VALUE$ DICT BASE DBTIMEZONE : NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS NLS_CHARACTERSET ZHS GBK NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD MON RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH MI SSXFF AM NLS_TIMESTAMP_FORMAT DD MON RR HH MI SSXFF AM NLS_TIME_TZ_FORMAT HH MI SSXFF AM TZH:TZM NLS_TIMESTAMP_TZ_FORMAT DD MON RR HH MI SSXFF AM TZH:TZM NLS_DUAL_CURRENCY $ NLS_P BINARY NLS_NCHAR_CHARACTERSET ZHS GBK NLS_RDBMS_VERSION NAME VALUE$ GLOBAL_DB_NAME SCPDB EXPORT_VIEWS_VERSION rows selected SQL> 从结果可以看出 NLS_LANG = AMERICAN _ AMERICA ZHS GBK 虽然 数据库的字符集是在create database的时候指定的 以后不允许改变 但在一个已经建立好的数据库上 我们可以通过修改SYS PROPS$来修改主要是对应客户端的显示 与存储无关 如 SQL> conn / as sysdba Connected SQL> SQL> select from sys props$ WHERE NAME= NLS_LANGUAGE ; NAME VALUE$ NLS_LANGUAGE AMERICAN SQL> SQL> UPDATE sys PROPS$ SET VALUE$= SIMPLIFIED CHINESE WHERE NAME= NLS_LANGUAGE ; row updated SQL> SQL> select from sys props$ WHERE NAME= NLS_LANGUAGE ; NAME VALUE$ NLS_LANGUAGE SIMPLIFIED CHINESE SQL> 通常出现问题的原因 可分为三种 服务器指定字符集与客户字符集不同 而与加载数据字符集一致 解决方法 对于这种情况 只需要设置客户端字符集与服务器端字符集一致就可以了 具体 *** 作如下 查看当前字符集 SQL> select from sys props$ WHERE NAME= NLS_CHARACTERSET ; NAME VALUE$ NLS_CHARACTERSET ZHS GBK SQL> 可以看出 现在服务器端Oracle数据库的字符集为 ZHS GBK 根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定 如果还没安装客户端 那么在安装客户端时 指定与服务器相吻合的字符集即可 如果已经安装好了客户端 并且客户端为 sqlnet 以下版本 进入Windows的系统目录 编辑oracle ini文件 用US ASCII替换原字符集 重新启动计算机 设置生效 否则 如果 客户端为 sqlnet 以上版本 在Win 下 运 行REGEDIT 第一步选HKEY_LOCAL_MACHINE 第二步选择SOFARE 第三步选择 Oracle 第四步选择 NLS_LANG 键 入 与服 务 器 端 相 同 的 字 符 集 （本例为 HKEY_LOCAL_MACHINE\ SOFARE\ORACLE\NLS_LANG AMERICAN _ AMERICA ZHS GBK） 如果是UNIX客户端 则 SQL> conn / as sysdba Connected SQL> SQL> UPDATE sys PROPS$ SET VALUE$= SIMPLIFIED CHINESE WHERE NAME= NLS_LANGUAGE ; row updated SQL> MIT; Commit plete SQL> 服务器指定字符集与客户字符集相同 与加载数据字符集不一致 解决方法 强制加载数据字符集与服务器端字符集一致 要做到这一点 可以通过重新创建数据库 并选择与原卸出数据一致的字符集 然后IMP数据 这种情况仅仅适用于空库和具有同一种字符集的数据 解决这类问题 也可以先将数据加载到具有相同字符集的服务器上 然后用转换工具卸出为foxbase 格式或access格式数据库 再用转换工具转入到不同字符集的Oracle数据库中 这样就避免了Oracle字符集的困扰 目前数据库格式转换的工具很多 像power builder 以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等 服务器指定字符集与客户字符集不同 与输入数据字符集不一致 对于这种情况 目前为止都还没有太好的解决方法 通过上面的了解 我们知道 导致在后期使用数据库时出现种种关于字符集的问题 多半是由于在数据库设计 安装之初没有很好地考虑到以后的需要 所以 我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦 lishixinzhi/Article/program/Java/hx/201311/27019

在Oracle系统中 用户使用特权用户身份（INTERNAL／SYSDBA／SYSOPER）登录Oracle有两种身份验证方法

使用与 *** 作系统集成的身份验证

使用Oracle数据库的密码文件进行身份验证

因此 管理好密码文件 对于控制授权用户从远端或本机登录Oracle数据库系统 执行数据库管理工作 具有重要的意义

Oracle数据库的密码文件存放有超级用户INTERNAL／SYS的口令及其他特权用户的用户名／口令 它一般存放在ORACLE_HOME＼DATABASE目录下

一 密码文件的创建

在使用Oracle Instance Manager创建一数据库实例的时侯 在ORACLE_HOME＼DATABASE目录下还自动创建了一个与之对应的密码文件 文件名为PWDSID ORA 其中SID代表相应的Oracle数据库系统标识符 此密码文件是进行初始数据库管理工作的基础 在此之后 管理员也可以根据需要 使用工具ORAPWD EXE手工创建密码文件 命令格式如下

C ＼ >ORAPWD　FILE=＜ FILENAME ＞　PASSWORD

=＜ PASSWORD ＞ ENTRIES=< MAX_USERS >

各命令参数的含义为

FILENAME 密码文件名

PASSWORD 设置INTERNAL／SYS帐号的口令

MAX_USERS 密码文件中可以存放的最大用户数 对应于允许以SYSDBA／SYSOPER权限登录数据库的最大用户数 由于在以后的维护中 若用户数超出了此限制 则需要重建密码文件 所以此参数可以根据需要设置得大一些

有了密码文件之后 需要设置初始化参数REMOTE_LOGIN_PASSWORDFILE来控制密码文件的使用状态

二 设置初始化参数REMOTE_LOGIN_PASSWORDFILE

在Oracle数据库实例的初始化参数文件中 此参数控制着密码文件的使用及其状态 它可以有以下几个选项

NONE 指示Oracle系统不使用密码文件 特权用户的登录通过 *** 作系统进行身份验证

EXCLUSIVE 指示只有一个数据库实例可以使用此密码文件 只有在此设置下的密码文件可以包含有除INTERNAL／SYS以外的用户信息 即允许将系统权限SYSOPER／SYSDBA授予除INTERNAL／SYS以外的其他用户

SHARED 指示可有多个数据库实例可以使用此密码文件 在此设置下只有INTERNAL／SYS帐号能被密码文件识别 即使文件中存有其他用户的信息 也不允许他们以SYSOPER／SYSDBA的权限登录 此设置为缺省值

在REMOTE_LOGIN_PASSWORDFILE参数设置为EXCLUSIVE SHARED情况下 Oracle系统搜索密码文件的次序为 在系统注册库中查找ORA_SID_PWFILE参数值（它为密码文件的全路径名） 若未找到 则查找ORA_PWFILE参数值 若仍未找到 则使用缺省值ORACLE_HOME＼DATABASE＼PWDSID ORA 其中的SID代表相应的Oracle数据库系统标识符

三 向密码文件中增加 删除用户

当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时 系统允许除INTERNAL／SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统 执行数据库管理工作 这些用户名必须存在于密码文件中 系统才能识别他们 由于不管是在创建数据库实例时自动创建的密码文件 还是使用工具ORAPWD EXE手工创建的密码文件 都只包含INTERNAL／SYS用户的信息 为此 在实际 *** 作中 可能需要向密码文件添加或删除其他用户帐号

由于仅被授予SYSOPER／SYSDBA系统权限的用户才存在于密码文件中 所以当向某一用户授予或收回SYSOPER／SYSDBA系统权限时 他们的帐号也将相应地被加入到密码文件或从密码文件中删除 由此 向密码文件中增加或删除某一用户 实际上也就是对某一用户授予或收回SYSOPER／SYSDBA系统权限

要进行此项授权 *** 作 需使用SYSDBA权限（或INTERNAL帐号）连入数据库 且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE 具体 *** 作步骤如下

创建相应的密码文件

设置初始化参数REMOTE_LOGIN_PASSWORDFILE＝EXCLUSIVE

使用SYSDBA权限登录

CONNECT　SYS／internal_user_passsword　AS　SYSDBA

启动数据库实例并打开数据库

创建相应用户帐号 对其授权（包括SYSOPER和SYSDBA）

授予权限 GRANT　SYSDBA　TO　user_name

收回权限 REVOKE　SYSDBA　FROM　user_name

现在这些用户可以以管理员身份登录数据库系统了

四 使用密码文件登录

有了密码文件后 用户就可以使用密码文件以SYSOPER／SYSDBA权限登录Oracle数据库实例了 注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED 任何用户以SYSOPER／SYSDBA的权限登录后 将位于SYS用户的Schema之下 以下为两个登录的例子

以管理员身份登录

假设用户scott已被授予SYSDBA权限 则他可以使用以下命令登录

CONNECT　scott／tiger　AS　SYSDBA

以INTERNAL身份登录

CONNECT　INTERNAL／INTERNAL_PASSWORD

五 密码文件的维护

查看密码文件中的成员

可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER／SYSDBA系统权限的用户的信息 表中SYSOPER／SYSDBA列的取值TRUE／FALSE表示此用户是否拥有相应的权限 这些用户也就是相应地存在于密码文件中的成员

扩展密码文件的用户数量

当向密码文件添加的帐号数目超过创建密码文件时所定的限制（即ORAPWD EXE工具的MAX_USERS参数）时 为扩展密码文件的用户数限制 需重建密码文件 具体步骤如下

（a）查询视图V$PWFILE_USERS 记录下拥有SYSOPER／SYSDBA系统权限的用户信息

（b）关闭数据库

（c） 删除密码文件

（d） 用ORAPWD EXE新建一密码文件

（e） 将步骤a中获取的用户添加到密码文件中

修改密码文件的状态

密码文件的状态信息存放于此文件中 当它被创建时 它的缺省状态为SHARED 可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态 当启动数据库事例时 Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置 当加载数据库时 系统将此参数与口令文件的状态进行比较 如果不同 则更新密码文件的状态 若计划允许从多台客户机上启动数据库实例 由于各客户机上必须有初始化参数文件 所以应确保各客户机上的初始化参数文件的一致性 以避免意外地改变了密码文件的状态 造成数据库登陆的失败

修改密码文件的存储位置

密码文件的存放位置可以根据需要进行移动 但作此修改后 应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置

删除密码文件

在删除密码文件前 大家应当确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE

lishixinzhi/Article/program/Oracle/201311/18956

单击开始，这里输入cmd，打开dos窗口

输入命令

exp bms/BMSPASS@TCDB file=E:\DBback\dbback20160112dmp

这里说明一下

这里的bms是指备份时，登录数据库实例TCDB的用户名；

这里的/是语法符号。

这里的BMSPASS是用户bms登录数据库TCDB时的密码；

@是语法符号。

这里的TCDB是Oracle数据库的实例名。

这里的file=E:\DBback\dbback20160112dmp 是只指备份文件的存放路径。

等待导出完成，如果看到这里的导出成功，说明备份完成了。

打开备份时指定的存储路径，就可以看到备份文件了。

如果在导出命令的最后加上full=y的参数，也就是

exp bms/BMSPASS@TCDB file=E:\DBback\dbback20160112dmp full=y

意思是将用户bms在TCDB数据库实例中的所有文件都备份，也就是完整备份。

数据库还原使用语法

imp bms/BMSPASS@TCDB file=E:\DBback\dbback20160112dmp

这里的E:\DBback\dbback20160112dmp是备份文件的存放路径

请添加详细解释

数据库的更新 *** 作再数据库内部分解的话也是两步：先把数据挪走，然后再插入。同时会产生很多的undo信息和日志信息。

至于你说的快慢问题：

1、当你删除用的是truncate 语句，然后再insert into的话，效率高于update。

2、当你删除用的始delete语句，然后再insert into的话，效率是低于update的。

当然这个只是从原理的角度进行了分析，对于不同的数据量和数据库配置和环境结果还是不一样的。

数据泵不一致导致的，比如说你用expbd导出来的用imp导入的时候就会出现这个错误，exp导出来的用imp导入;

expbd导出来的用impbd导入。

和版本没有关系，导出库时用的oracle版本和导入时用的不同。小版本不同也有影响。

解决办法：使用相同的数据泵导入导出。

OracleDatabase，又名OracleRDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。

ORACLE数据库系统是美国ORACLE公司（甲骨文）提供的以分布式数据库为核心的一组软件产品，是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。比如就是基于数据库的一种中间件。ORACLE数据库是目前世界上使用最为广泛的数据库管理系统，作为一个通用的数据库系统，它具有完整的数据管理功能；作为一个关系数据库，它是一个完备关系的产品；作为分布式数据库它实现了分布式处理功能。但它的所有知识，只要在一种机型上学习了ORACLE知识，便能在各种类型的机器上使用它。

Oracle数据库最新版本为OracleDatabase12c。Oracle数据库12c引入了一个新的多承租方架构，使用该架构可轻松部署和管理数据库云。此外，一些创新特性可最大限度地提高资源使用率和灵活性，如OracleMultitenant可快速整合多个数据库，而AutomaticData和HeatMap能以更高的密度压缩数据和对数据分层。这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强，使得Oracle数据库12c成为私有云和公有云部署的理想平台。

以上就是关于Oracle数据库的管理全部的内容，包括:Oracle数据库的管理、怎样管理好ORACLE数据表、oraclecount一直出不来数量,如何优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！