在日常工作中oracle数据库的日志空间不足只能进行什么 *** 作

在日常工作中oracle数据库的日志空间不足只能进行什么 *** 作,第1张

在日常工作中oracle数据库的日志空间不足只能进行清理空间 *** 作。

1、扩大表空间现有数据文件的大小。

2、oracle用户登录数据库服务器,用sysdba连接数据库sqlplus,assysdba即可。

确认不在需要的日志需要进行清理:

$ORACLE_BASE/admin/<SID>/bdump/alert_<sid> echo > alert_<sid>log

$ORACLE_HOME/network/log/listenerlog: echo >listenerlog

$ORACLE_BASE/admin/udump/trc: rm –rf trc

分区表和磁盘碎片没什么关系的,分区表并不是指把表分成一个个不同的物理实体去存放成不同的文件

你可以把分区表存在不同的表空间,也可以存放在相同的表空间

目的,只是为了更好地改善查询性能,对分区表建立不同的分区索引,增强维护性,比如你的一个分区所在表空间挂掉,可以只修得当前挂掉的,其他的还是好的,可以减少IO冲突

数据库的表很多 总共加起来有 多个表 占十几个G左右空间

请问表空间如何设置

是设置在USERS表空间内建立一个十几G的数据文件USERS DBF呢?

还是在USERS表空间内建立三个几G的数据文件USERS DBF USERS DBF USERS DBF

表空间内的数据文件以多大上限最好?是越大的单个文件好呢?还是小一点的多个文件好?以什么为原则?

ORACLE数据库产生许多碎片怎么办?存储数据文件的这个盘符 可以定期做 磁盘碎片整理 吗?该怎么做?要不要先把数据库关掉再做?

两个数据库同时运行在一个服务器上面 为两套业务系统服务

两个数据库共用一个对外端口 合理吗?会不会影响数据吞吐性能?要不要一个用 端口 一个用 端口 开两个监听程序这样设置?

分成多个数据文件

原因是

( )有些 *** 作系统对文件大小有限制 或者安装是做过限制 你不一定清楚这些限制 而且某些版本的传输协议不支持过大的文件 例如AIX某版本的sftp就不允许传输文件超过 G

( )你现在数据量小 所以不用考虑太多 但将来数据量增大以后 要考虑负载均衡 就要把部分数据文件挪到其他盘上 多个数据文件会使这样很容易

( )当你的数据文件某部分出现坏块之后 你需要让某个数据文件暂时offline恢复等等 如果你的数据文件过大 影响也可能更大

( )使用RMAN备份的时候 单独备份数据文件 恢复也可单独恢复 因此很显然分多个数据文件有好处

单个数据文件的大小 这个要考虑的东西比较多 比如你的存储性能 比如你的总数据量 等等 专家的建议是 对于几十G到几百G的数据量 单个数据文件的大小一般在 - G 原则有一套理论说明的 但是我忘了 只说一下个人的建议

( ) *** 作系统限制 这个如果没有注意到很容易出问题 特别是自扩展的数据文件 例如system undotbs等等

( )表空间的大小 要考虑单个数据文件移动或恢复的情况 显然如果对于几十个G的表空间 就分成两个数据文件 并不能对你的 *** 作带来什么好处

( )全凭经验把握的东西 还要考虑的你硬盘的raid情况等等 情况比较复杂 只能折衷 不能简单的一概而论说大就好或者小就好

当然这并不是主要的 你没必要太关注这方面的东西 因为对于你这样的简单环境来说 区区一个表空间数据文件大小的修改 对性能的提高甚至不如多建一条索引大!

数据库产生碎片怎么办 我告诉你 数据库的碎片和windows说的那个碎片整理是两码事 你不要混淆 windows再怎么整理也是没用的

其实我坦白的跟你讲 你几十个G的数据库 短期根本就不用考虑什么碎片问题 这种情况得等大家都反映数据库开始变慢了 再考虑回收段空间等等 而且你都说 是否要关闭了再做 说明你的数据库可以关 也就暗示了它 不是很忙 那么最近 - 年之内你不用考虑做这件事了

两个数据库同时用一个监听器 当然不合理 你一个监听器挂了两个数据库都连不上去 你不觉得这样风险很大么?

两个公用一个端口 对数据的吞吐性能是没有任何影响的 这个你不用担心 但是安全性无疑很低

所以当然有必要用两个端口 和 其实我建议你把两个数据库安装在两个不同的 *** 作系统用户下面 这样大家彼此逻辑都清楚 影响小 带来的好处你能慢慢体会到 这纯粹是从我的工作经验来建议你的 如果你嫌麻烦当我没说

如何设置?你这个问题问的复杂了 我可懒得把编辑TNS的一堆写出来

lishixinzhi/Article/program/Oracle/201311/17231

本文希望通过系统地介绍这方面的有关概念 让大家能更好地规划使用数据空间 正确使用Oracle提供的有关功能特性 提高应用的执行效率

数据库空间的有效使用和维护不仅是数据库管理的重要工作 也是大多数开发人员所关心的内容 因为它直接关系到数据库性能的发挥 同时数据碎片是经常令人头疼的问题 碎片不仅造成空间的浪费 更重要的是会直接影响应 用程序的响应速度

Oracle提供了不少方法用于数据空间的使用 监控和维护 同时也在各版本中陆续对这方面的功能进行了增强 目的在于简化这方面工作的复杂度 提高应用的运行效率

一 相关概念

数据库的空间在逻辑上分为多个表空间 每个表空间则由系统中的一个或多个物理数据文件构成 Oracle存储数据的基本单位是块 其大小在建库时由DB_BLOCK_SIZE参数确定 一个或多个连续的块构成一个区片(EXTENT) 它作为数据对象存储的基本单位来使用 在Oracle中 每个基本数据对象使用的空间称为段(Segment) 段存放在唯一的表空间上 每个段实际上是一系列区片(更为准确地是数据块)的集合 每个简单数据对象对应一个段 对于分区对象如分区表 索引 则每个(子)分区对应一个段 由各个(子)分区共同构成一个完整的数据对象 因此 可以把表空间看作桶 里面放著许多段 一个段只能放在一个桶中 而不能跨越多个桶

二 表空间的使用

表空间碎片的产生

由于同一个表空间中存放有多个数据段 各个数据段可以有不同的区片尺寸 不同段的区片可以交叉存放 当这些段中的区片经过分配(如创建表) 释放(如删除表)后 就可能使表空间中原本连续的空闲数据块变成不连续 而区片必须由连续的数据块构成 这时 当某一段需要分配新的区片时 就有可能出现虽然表空间空闲数据块的总和大于所需区片的大小 但却无法找到一串连续的块来供此区片分配使用 这种情况就称为表空间的Extent Fragmentation 我们经常会遇到这种情况 明明从DBA_FREE_SPACE中计算表空间还有几百MB 但其中的某一个表却无法再扩展几个MB的空间

消除表空间碎片

Oracle在段的区片分配上为用户提供了很大的灵活性 然而如果未能正确使用创建表空间和数据对象的各个可选择参数 则在最后将不可避免的要面对区片碎片的问题 Oracle 的Bhaskar Himatsingka 和 Juan Loaiza 为此提出了SAFE(Simple Algorithm for Fragmentation Elimination )配制规则 通过遵循这套规则 区片级碎片可以完全的避免 而实际上 Oracle i引入的新特性 Local Managed Tablespace就是SAFE规则在Oracle Server的内置实现 SAFE原则概括起来包括

对每个表空间上的段使用相同的区片尺寸 段参数INITIAL=NEXT PCTINCREASE= 可以通过使用Create Tablespace 的 MINIMUM EXTENT 子句来确保分配的区片是此参数的倍数

仅在表空间级指定INITIAL NEXT参数 在创建数据段时不要指定这些参数

区片的大小根据段大小来确定 原则是均衡顺序扫描的效率和空间的利用率 同时确保段的区片数目控制在 之下 根据此原则 在进行相应测试之后 确定以下区片选取规则

段大小(Oracle ) 区片大小(Oracle ) 段大小(Oracle ) 区片大小(Oracle ) & M K & M K M G M M G M & G M & G M

有此数据库中可以只使用三种区片大小的表空间 在对象创建之前需对其大小进行评估 并放到相应的表空间中

Oracle 引入了本地管理表空间 它在管理和性能上都优于传统的字典管理表空间 它已融合了规则 要使用此特性 在CREATE TABLESPACE语句中指定EXTENT MANAGEMENT LOCAL子句

段的区片数目上限应在 之下 DML *** 作在此区片数目范围内不会有明显的性能差异 但某些DDL *** 作的速度则与区片的数目关系较大 因此合理的区片数目应保持在 之下 对于持续不断扩展的段 应监控区片数目 在必要时移至其它表空间

对于特别大的数据段应控制在 G G(Oracle 为 G G)之间 它们应存放到单独的表空间上 同时对于这些特大段应考虑使用分区拉提高性能

用户的临时表空间应使用TEMPORARY类型

当系统的事务规模比较均衡时可以对回滚段使用OPTIMAL参数 否则应避免制定OPTIMAL参数 而定期监控回滚段的大小 并在必要时重建

临时段和回滚段绝对不要将用户数据存放到SYSTEM表空间 它是专为永远不会Drop和Truncate的系统数据对象而设计的

创建表空间时指定数据文件的大小应=区片整数倍+ 数据块 对于Local Managed Tablespace则为区片整数倍+ K

当表空间使用统一的区片大小时 不要对其进行空间整理 重整的结果不仅耗费精力而且可能会使性能变差 对于未使用统一的区片尺寸的表空间应通过Export/Import重整

i 提供了Alter Table …Move [Tablespace…]命令可用于快速重整表 Alter Index …Rebuild…[Tablespace…] 命令可用于快速重建索引

有关使用单个区片的误导

在许多关于碎片整理的文档中建议在Export时使用Compress=Y选项 将表中的所有数据调整到一个区片中 期望在Import后获得良好性能 由此让许多人产生一个观点 认为当表中数据全部存放到一个区片中时 可以获得良好性能 实际上单区片段只在以下条件成立时 才具有优越性

数据主要以(全段)扫描方式访问

段所对应的数据块在物理磁盘上连续存放 Oracle可以发布较大的顺序磁盘读 *** 作

通过对这两条进行分析可以发现 一方面数据库中大部分表是通过索引来访问 另一方面现在的数据库文件一般在物理上使用了RAID 或RAID + 技术 数据以条带化方式分布到多个物理磁盘上 逻辑上的单个区片和多区片在物理上并无本质上的区别 另外 从Oracle的角度来看 管理几百个区片的段是非常轻松的并不会有性能的下降 由此可见将整个段放到一个区片中并无明显好处 而这种做法却会导致表空间碎片的产生

三 表数据段的使用

表空间的组织

Heap表的空间由一系列区片链接而成 每个数据块除块头外其余部分可用于存放数据 在创建表时可以指定以下参数

PCTFREE 块中保留用于UPDATE *** 作的空间百分比 当数据占用的空间达到此上限时 新的数据将不能再插入到此块中

PCTUSED 指定块中数据使用空间的最低百分比 当一个块在达到PCTFREE 之后经历了一些DELETE *** 作 在其空间使用下降到PCTUSED后便可以重新被用于INSERT数据 这就是PCTFREE/PCTUSED参数的含义

调整PCTFREE PCTUSED参数的目标一方面是提高性能 另一方面则主要是提高空间使用效率 避免出现块中存在有许多未用的空间 但却无法找到一个块可以被用于插入新数据行的情况发生

PCTFREE的使用

在Oracle中表的每一行数据由唯一的ROWID标记 而Oracle支持的数据类型中有一些长度是可变的 如VARCHAR 当对这些数据进行UPDATE时 如果块中的可用空间不能容纳UPDATE后的数据行时 Oracle将会把此行移到其它数据块 同时保留此数据行的ROWID不变 并在原有块中建一指针指向行迁移后的位置 在这种情况下读取一行数据将需要访问 个数据块 从而导致性能下降 PCTFREE保留的空间就是为确保更改后的数据行可以仍存放于原有数据块中 避免行迁移的情况发生

由此 如果PCTFREE设置不足时可能产生行迁移 而另一方面如果PCTFREE设置过高 将会造成空间浪费 因此正确设置PCTFREE需要对表中数据的使用进行分析 对于数据长度不会变化或极少更新的情况 可以采用较小的PCTFREE 对于其它大多数情况应采用稍大的PCTFREE(PCTFREE的缺省值是 如果不好估计需预留的空间 可以使用 的范围) 不要为节约块中的空间而使用较小的PCTFREE值

PCTUSED的使用

当块的使用的空间下降到PCTUSED后 此块被重新放回空闲链表(Freelist)中 作为后续Insert的候选块 同样 设置PCTUSED需要视数据行的特性和Insert Update Delete的模式而定 但必须遵守的原则是 db_block_size ( PCTFREE PCTUSED)必须比行的长度大

对于数据行长度变化较大的情况 应使用最大行长度来计算PCTUSED 并且应使用较低的PCTUSED值 因为在执行Insert时 如果数据块的可用空间不能装下一行数据 当块的使用的空间是在PCTUSED之上 Oracle将把此块从Freelist中移走 当块的使用的空间是在PCTUSED之下 Oracle将会扩展段空间 因此 PCTUSED如果设得过高 将导致段的不断扩展

lishixinzhi/Article/program/Oracle/201311/18776

以上就是关于在日常工作中oracle数据库的日志空间不足只能进行什么 *** 作全部的内容,包括:在日常工作中oracle数据库的日志空间不足只能进行什么 *** 作、oracle数据清理数据库日志、Oracle分区表,经常删除会造成磁盘碎片过多吗等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9823122.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存