oracle数据库创建好实例之后没有pfile和spfile文件夹怎么办

oracle数据库创建好实例之后没有pfile和spfile文件夹怎么办,第1张

你说的是文件夹?还是文件?

数据库创建好以后spfile是很定存在的,不然数据库是没办法启动的。

有一个动态视图(V$PARAMETER)是可以查询spfile的位置的。

如果两个文件都丢了,那就重做,可以重做pfile的,怎么重做忘记了,你查查看吧,网上应该有。

一 更改日志 *** 作模式三步走

默认情况下 Oracle数据库采用的是非归档模式 但是 非归档模式不能够防止因物理损坏而导致丢失数据问题 为此数据库管理员可能需要把日志 *** 作模式从非归档模式转换为归档模式 其实 要进行这个转换的话 只需要通过简单的三个步骤即可 不过在进行 *** 作之前 要需要注意 以下的 *** 作都必须要求用户具有数据库管理员的权限 即只有SYSDBA或者SYSOPER身份才能够执行如下的 *** 作

要更改日志 *** 作模式 具体 *** 作步骤如下

第一步 先确定当前的日志 *** 作模式 当数据库管理员更改当前 *** 作日志模式之前 需要先确定一下当前日志 *** 作模式 此时数据库管理员可以查询动态性能视图 来确认当前日志 *** 作模式 如可以利用如下语句来查询我们所需要的信息 动态性能视图中存储著很多数据库运行信息 从中我们数据库管理员可以获取很多有用的信息 如现在要了解当前数据库的日志 *** 作模式 就可以从数据库动态性能视图中获知

第二步 关闭数据库 如果确认数据库当前的日志 *** 作模式为非归档模式 需要把它改为归档 *** 作模式 需要先关闭当前运行的数据库 然后重新装载数据库 需要注意的是 更改日志 *** 作模式只能够在MOUNT状态下进行 因此必须首先关闭数据库 然后重新装载数据库 另外 如果需要更改日志 *** 作模式 那么在关闭数据库时不能够使用SHUTDOWN ABORT命令 SHUTDOWN ABORT命令的作用其实跟KILL进程具有同样的效果 若利用这个命令的话 可能会给数据库带来一些不利的因素 如可能导致文件状态不一致 在数据库正常关闭的时候 数据库会同步校验各个文件 使得重新启动的时候文件时间点一致并且不用进行崩溃修复 而使用这个命令不会进行这个检验 所以 采用SHUTDOWN ABORT命令关闭数据库的时候 可能会导致数据库启动出错 导致已经递交的数据丢失 甚至出现数据库崩溃的噩梦 所以 无论是在更换数据库日志 *** 作模式 又或者其他原因需要关闭数据库的 最好不要采用这个命令 只有在采用其他关闭数据库命令不能够奏效的情况下 才能够使用这个命令 笔者建议通过SHUTDOWN IMMEDIATE命令来关闭数据库

数据库关闭之后 再利用Startup命令 把数据库启动到MOUNT状态 再次提醒一次 只有在Mount状态下才能够更改日志 *** 作模式

第三步 更改日志 *** 作模式 以上准备工作做好之后 就可以利用相关命令来更改日志 *** 作模式 我们可以利用如下命令来进行更改

然后重新打开数据库之后 设置就生效了

二 手工对重做日志文件进行归档

有时候出于某些原因 数据库管理员可能需要手工对重做日志进行归档 在 G以后的版本中 默认情况下 当将日志 *** 作模式从非归档模式转换为归档 *** 作模式的时候 Oracle数据库会在后台自动启动一个ARCH进程 这个进程就是负责重做日志的备份任务 通常情况下 归档模式下 数据库会自动备份重做日志

若需要手工备份重做日志的话 即手工归档 则必须在改变 *** 作日志模式中明确说明 即在上面的命令中 加入MANUAL参数 如果加入这个参数后 则数据库管理员就必须手工执行归档命令 如果数据库管理员没有手工执行归档命令的话 则日志组中的内容就无法被进行覆盖 所以通常情况下 除了一些特殊的需要 如数据库测试 才使用手工归档方式 否则的话 就还是采用自动归档方式更加的合理 值得一提的是 根据笔者了解 这个参数只是一个过渡参数 主要为了跟以前的Oracle数据库版本兼容 估计在不久之后 这个手工归档的参数会取消掉

三 设置归档文件的存储位置

在 *** 作系统管理中 系统管理员往往会重新设置我的文档 IE收藏夹等存储位置 以防止系统奔溃时这些数据的丢失 其实 在Oracle归档日志文件管理中也是如此 当数据库管理员把日志 *** 作模式从非归档模式转换为归档模式时 需要根据实际情况 重新设置归档文件的存储位置

当数据库处于归档模式时 如果进行日志切换 后台进程将自动生成归档日志文件 归档日志文件的默认存储位置为Oracle数据库安装目录下的RDBMS下 而在实际工作中 数据库管理员往往会改变其存储位置 如出于空间的考虑或者安全方面的考虑 会把归档日志存放在数据文件不同的硬盘中 等等

如果需要更改归档日志的 *** 作文件 则需要变更相应的初始化参数 参数Log Archive Dest就是用来控制归档日志的存储路径的 通常情况下 若是没有备用数据库的话 则只需要把归档日志存放到服务器上的独立的硬盘中即可 而不需要进行异地备份 如果需要配置本地归档日志的存储路径 则可以通过以上的初始化参数以及Log Archive Duples_Dest参数 其中前面一个参数用来指定第一个归档日志的位置 第二个参数用来指定第二个归档日志的位置 当分别对以上两个参数进行配置后 数据库系统在进行日志切换时 后台进程就会生成两份完全相同的归档日志 分别存储在上面两个不同的路径中 这里需要强调的一点是 存放在两个不同路径中的归档日志文件是完全相同的 这主要是出于数据安全的需要 一般情况下 只需要一个归档日志即可 若不放心的话 则可以设置多个归档日志存放位置 不过这些归档日志最好能够存放到不同的磁盘上 否则的话 就没有多少的实际意义

除了以上这个配置参数之外 平时工作中 我们还经常会使用Log Archive Dest_N这个参数 这个参数主要用于指定多个归档位置 通常情况下 可以多大十个归档位置 这个参数跟先前提到的两个参数有比较大的不同 数据库管理员要对此有清晰的认识 只有如此 才能够根据自己的需要 选择合适的初始化参数 他们的差异主要有以下几点

一是不带N的初始化参数(即前面的两个参数)只能够用来配置本地归档位置 而后面谈到的这个参数这可以用来配置本地归档位置与远程归档位置 也就是说 如果数据库管理员要把归档日志文件保存在网络上的其它主机中时 就必须利用后面的参数进行配置 这个区别是几个参数之间最大的差异 不过由于网络传输等方面的限制 笔者并不建议把归档日志保存在其它主机上 而是建议在数据库服务器中增加一块独立的硬盘用来保存归档日志文件即可 因为硬盘之间数据的复制要比网络传输要快的多 这可以避免重做日志归档时对网络资源过多的占用 从而降低网络的性能

二是前面两个参数只能够配置两个不同的归档日志位置;而后面一个参数则可以配置多大十个归档日志文件位置 这是两者数量上的差异 不过没什么作用 对于大部分企业来说 可能两个归档日志文件存放位置已经可以满足他们的需求了 另外一个小的差异就是 后面这个参数不能够跟前面两个参数共存 为此 当使用后者这个参数时 就需要先把前面两个参数禁用掉 因为数据库默认情况下 是启动第一个初始化参数的

三是具体的配置也有所不同 利用后者参数指定归档日志存储位置时 如果配置本地归档位之 则需要指定Location选项;如果是配置远程归档日志位置时 则就需要制定Service选项 这个选项主要用来指定远程数据库的网络服务名 通常情况下 数据库管理员可以同时配置本地归档位置与远程归档位置

lishixinzhi/Article/program/Oracle/201311/18259

schema是数据库中的一个概念 。专指所有对象的集合,这里的对象不是指users ,而是说的tables , sequences , trigers , views这些东西。所以通常意义上,可以通过查询user_objects这类的静态视图 ,来获知当前用户包含哪些对象。当你是dba用户时,可以通过dba_users查询当前库包含哪些用户,再通过dba_objects可以查出每个用户拥有哪些对象。

有两种办法

1、TRUNCATE TABLE 删除表中的所有行,而不记录单个行删除 *** 作。

语法 TRUNCATE TABLE name

参数 name 是要截断的表的名称或要删除其全部行的表的名称。

2、Delete from tablename where 1=1

在Oracle数据库中 创建索引虽然比较简单 但是要合理的创建索引则比较困难了 笔者认为 在创建索引时要做到三个适当 即在适当的表上 适当的列上创建适当数量的索引 虽然这可以通过一句话来概括优化的索引的基本准则 但是要做到这一点的话 需要数据库管理员做出很大的努力 具体的来说 要做到这个三个适当有如下几个要求

一 根据表的大小来创建索引

虽然给表创建索引 可以提高查询的效率 但是数据库管理员需要注意的是 索引也需要一定的开销的 为此并不是说给所有的表都创建索引 那么就可以提高数据库的性能 这个认识是错误的 恰恰相反 如果不管三七二十一 给所有的表都创建了索引 那么其反而会给数据库的性能造成负面的影响 因为此时滥用索引的开销可能已经远远大于由此带来的性能方面的收益 所以笔者认为 数据库管理员首先需要做到 为合适的表来建立索引 而不是为所有的表建立索引

一般来说 不需要为比较小的表创建索引 如在一个ERP系统的数据库中 department表用来存储企业部门的信息 一般企业的部分也就十几个 最多不会超过一百个 这 条记录对于人来说 可能算是比较多了 但是对于计算机来说 这给他塞塞牙缝都还不够 所以 对类似的小表没有必要建立索引 因为即使建立了索引 其性能也不会得到很大的改善 相反索引建立的开销 如维护成本等等 要比这个要大 也就是说 付出的要比得到的多 显然违反常理

另外 就是对于超大的表 也不一定要建立索引 有些表虽然比较大 记录数量非常的多 但是此时为这个表建立索引并一定的合适 如系统中有一张表 其主要用来保存数据库中的一些变更信息 往往这些信息只给数据库管理员使用 此时为这张表建立索引的话 反而不合适 因为这张表很少用到 只有在出问题的时候才需要查看 其次其即使查看 需要查询的纪录也不会很多 可能就是最近一周的更新记录等等 对于对于一些超大的表 建立索引有时候往往不能够达到预计的效果 而且在打表上建立索引 其索引的开销要比普通的表大的多 那么到底是否给大表建立索引呢笔者认为 主要是看两个方面的内容 首先是需要关注一下 在这张大表中经常需要查询的记录数量 一般来说 如果经常需要查询的数据不超过 %到 %的话 那就没有必要为其建立索引的必要 因为此时建立索引的开销可能要比性能的改善大的多 这个比例只是一个经验的数据 如果数据库管理员需要得出一个比较精确的结论 那么就需要进行测试分析 即数据库管理员需要测试一下全表扫描的时间 看看其是否比建立索引后的查询时间要长或者短 如果是长的话 则说明有建立索引的必要 但是如果没有的话 则说明还是全表扫描速度来的快 此时也就没有必要建立索引了

总之 在考虑是否该为表建立索引时 一般来说小表没有建立索引的必要 而对于打表的话 则需要进行实际情况实际分析 简单一点的 可以根据大致的比率来确定 如果要精确一点的 则可以进行全表扫描性能分析 以判断建立索引后是否真的如预期那样改善了数据库性能

二 根据列的特征来创建索引

列的特点不同 索引创建的效果也不同 数据库管理员需要了解为哪些列创建索引可以起到事倍功半的效果 同时也需要了解为哪些列创建索引反而起到的是事倍功半的效果 这有利于他们了解到底给为怎么样的字段建立索引

根据笔者的经验 往往为如下特征的列创建索引能够起到比较明显的效果 如对于一些重复内容比较少的列 特别是对于那些定义了唯一约束的列 在这些列上建立索引 往往可以起到非常不错的效果 如对于一些null值的列与非Null值的列混合情况下 如果用户需要经常查询所有的非Null值记录的列 则最好为其设置索引 如果经常需要多表连接查询 在用与连接的列上设置索引可以达到事半功倍的效果

可见 索引设置的是否恰当 不仅跟数据库设计架构有关 而且还跟企业的经济业务相关 为此 对于一些套装软件 虽然一开始数据库管理员已经做了索引的优化工作 但是随着后来经济数据的增加 这个索引的效果会越来越打折扣 这主要是因为记录的表化影响到了索引优化的效果 所以笔者建议各位数据库管理员 即使采用的是大牌软件公司的套装软件 也需要隔一段时间 如一年 对数据库的索引进行优化 该去掉的去掉 该调整的调整 以提高数据库的性能

如在数据库中有一张表是用来保存用户信息的 其中有个字段身份z号码 这是一个唯一的字段 在数据库设计时 给这个字段创建了索引 但是当这个数据库投入使用之后 用户不怎么输入用户的身份z号码 而且平时也基本不按这个号码来进行查询 当记录月来月多时 这个身份z号码上的索引字段不但不能够改善数据库的查询性能 反而成了鸡肋 对于这些有很多NULL值的列 而且不会经常查询所有的非NULL值记录的列 数据库管理员要下决心 即使清除这些列上的索引

所以说索引的优化与调整是一个动态的过程 并不是说数据库设计好之后就不需要经过调整 数据库管理员往往需要根据记录的变化情况 来进行适当的变更 以提高索引的效果

三 在一个表上创建多少索引合适

虽然说 在表上创建索引的数量没有限制 但是决不是越多越好 也就是说 在创建索引这项事情上 + 〉 往往不成立 有时候 创建索引越多 其可能会得到适得其反的效果 那么在一个表上 到底给创建多少索引合适呢这个没有一个明确的标准 而是需要数据库管理员根据实际的用途以及数据库中记录的情况 来进行判断

通常来说 表的索引越多 其查询的速度也就越快 但是 表的更新速度则会降低 这主要是因为表的更新(如往表中插入一条记录)速度 反而随着索引的增加而增加 这主要是因为 在更新记录的同时需要更新相关的索引信息 为此 到底在表中创建多少索引合适 就需要在这个更新速度与查询速度之间取得一个均衡点 如对于一些数据仓库或者决策型数据库系统 其主要用来进行查询 相关的记录往往是在数据库初始化的时候倒入 此时 设置的索引多一点 可以提高数据库的查询性能 同时因为记录不怎么更新 所以索引比较多的情况下 也不会影响到更新的速度 即使在起初的时候需要导入大量的数据 此时也可以先将索引禁用掉 等到数据导入完毕后 再启用索引 可以通过这种方式来减少索引对数据更新的影响 相反 如果那些表中经常需要更新记录 如一些事务型的应用系统 数据更新 *** 作是家常便饭的事情 此时如果在一张表中建立过多的索引 则会影响到更新的速度 由于更新 *** 作比较频繁 所以对其的负面影响 要比查询效率提升要大的多 此时就需要限制索引的数量 只在一些必要的字段上建立索引

笔者在平时数据库优化时 往往会根据这些表的用途来为列设置索引 可以查询相关的动态视图 看看对于这张表的 *** 作 是更新 *** 作(包括更新 删除 插入等等)占的比例大 还是查询 *** 作占的比例大 当过多的索引已经影响到更新 *** 作的速度时 则数据库管理员就需要先禁用某些索引 以提高数据库的性能

lishixinzhi/Article/program/Oracle/201311/18407

监控Oracle 数据库中长时间运行进程的两种方式,通过这些方 法,我们可以监控单条语句的 长时间 *** 作,监控存储过程的运行进度,甚至自己'生成'进度信息 关键词:监控进度V$SESSION_LONGOPS 当Oracle 存储过程运行时间较长时,我们希望客 户端能了解到它在后台执行的状况或者进度信息(类 似WINDOWS 安装软件时的进度条信息),这样可以知 道运行在后台的应用进程是否终止或者休眠,更近一 步要求,最好能知道进行到哪一步骤,还有多少时间才 能完成 简单到一条SQL 语句的情况,如果执行时间较长, 我们如何得到它的运行状况是否后台还在运行虽 然可以查看SQL 的执行计划了解它的执行步骤,但如 何知道它运行到哪一个步骤了呢如何才能估计出它 的合理的较为精确的执行时间呢 Oracle 数据库前端发出执行命令后,进程在后台 执行,普通开发人员一般无法了解到后台在做什么,一 般采用的方法是用DBMSOUTPUTPUT_LINE 来打印出 来,但DBMS—OUTPUTPUT—LINE 打印的信息受缓冲区 大小限制,如果信息较多就容易溢出,而且如果存储过 程执行时间较长,只有在其执行完后,这些信息才会打 印出来,这就增加了调试周期,影响了调试效果有的 开发人员在存储过程中通过写日志表的形式来记录进 度,但需要COMMIT 后其他进程才能看到这些日志信 息,而在某些控制结构中(如游标CURSOR 循环)COM— MIT,则很容易引起ORA 一01555 错误,造成程序出错 下面介绍两种监控方法 如何监控单条长语句从ORACLE8 开始,出现一个新的动态视图:V $SESSION_LONGOPS,从这个视图可以获知一些 *** 作 (如全表扫描,并行查询,RMAN,排序等)的执行进度, 我们先来了解一下V$SESSION—LONGOPS 视图的一些 重要字段: 列说明 sID 会话标识 5ERIAL#会话序列号 OPfE *** 作的简短描述 TARG 盯 *** 作的对象,如xx TAR~_DESC目标描述 SOFAR 目前已执行单位数目 ToTAIWORK 总单位数目 UNlTS 单位 START_TIME 开始执行时间 LAST_ UPDATE_TIME 统计数据最后更新时间 TIME_ REMAINING 估计剩余时间c ELAPSED_SECONDS 已执行时间(秒) MEsSAGE 统计数据汇总信息 USERA^^E 用户名 ~L_ADDRES5 语句的地址,,用于和V$sql_text 等关联 语句的hash 地址,用于和V$sql_texlSQLHASH VALUE等关联 这个动态视图显示各个运行时间超过6 程这些进程包含许多备份和恢复功能,统计数据收集,查询等 执行以下语句就可以得到数据库中各个长时间 *** 作的进程信息: select'Icfromv$sesslon_ longopswheretime_ re- malnlng>0 我们也可以用图形化工具查看,如TOAD,OEM中 均可查看长 *** 作进程进度信息 Oracle 自带的管理工具OracleEnterpriseManager (OEM)提供了图形化查看长 *** 作的功能,如: 计算机系统应用2007 Quest公司的数据库管理工具TOAD 也可以看到 长 *** 作信息,如: 表的统计信息 长时问运行的SQL 语句可以用V$SESSION—LON 为了能监控到查询进程执行的进度,必需使用 CBO 优化器并且: 设置TlMED—STATISTICS或者SQL—TRACE 用ANALYZE语句或者DBMS—STAT 包收集相关 108 实践经验P 帕cficalExpen GOPS来监控实际上,长时间运行的存储过程也可以 监控那是否任何 *** 作都可以通过这个视图来监控进 度呢很遗憾,V$SESSION—LONGOPS 只会报告它认为 耗时长的 *** 作对于NEsTEDLOOP/UNIQUEINDEX READS/INDEXRANGEScANS 等执行速度很快的 *** 作, 2007 期计算机系统应用由于它们执行一般不超过6 秒,因此将不会出现在V $SESSION—LONGOPS 如何监控自定义存储过程单条长语句可以用上面的方法监控,Oracle 动生成V$SESSION— LONGOPS 记录那么存储过程中 有许多小 *** 作,如何监控进度呢其实,我们也可以手 工生成V$SESSION—LONGOPS 记录,方法是调用DBMS APPLICATION—INFO 包来生成自定义进度信息 从Oracle72 开始,提供了DBMS—APPLICATION— INFo 包,通过调用这个包,应用可以将自己的名字和 动作填写到V$SESSION 和V$SQLAREA 的MODULE ACTION列中V$SESSION 列出每个会话的用户名, *** 作系统机器名,终端名,程序名等 应用可以在执行模块时设置模块名和动作名,模 块名一般是甩户自定义的而动作名一般描述模块中 的当前执行的事务的名字 DBMSAPPLICATION_INFO 包包含以下过程 SET_ MODULE 设置当前运行程序的模块名 SET__AEl'ION 设置当前模块的当前动作名 SESSION—LON-在V$SESSIONLONGOPS视图中 GoPS 插入一行进度信息 SETMODULE过程设置模块名和动作名: createorreplaceproceduredel—cust(v_cust—Id varchar2) begindbms—— application—— infoset— module(module—— name=>"delcust" actlon_name=>"deletetablecust)i deletefromcustwherecustld=v_ cusLId; dbms_appllcatlon— InfoseLmodule(,); end;以上设置的模块名和动作名可以通过查询V $sqlarea 获取 如:selectsql—text,module,actionfromv $sqlareawheremodule="del_cust: sql_textmoduleadion Deletefr0mcustdel_ custdeletetableoust 1rowselected SET_SESSION—LONGOPS 过程用于在V$session— longops 中插入一行,开发人员可以调用此过程设置长 时间 *** 作的状态信息,这样,任何其他其他会话都可以 看到这个进度信息如下例所示: declare nohlntnumberdefaultdbmsapplicatlon_infoset_ session— Iongops_ nohint; IdndexnumberdefaultInohlnt: slnonumber;begin forlIn18888888888 loop update; dbms_ appllcaflon— Infosetsesslon_ longops (rlndex=>l_rlndex, slno=>I_slno op_name=>"updateahugetable target=>126, target_desc=>'msgdescription context=>0sOfar=>j totalwork=>8888888888 units=>loops endloop;end; 然后,从另一个会话来执行以下语句selectfromv$sesslon_ longopswheretlmere malnlng>0; 也可以用图形化工具TOAD 或OEM来查看 因此,采用本文说明的方法,Oracle 开发人员可以 比较方便的监控长 *** 作进程的进度信息,也可以自己 设置监控信息,来了解后台存储过程的运行效率甚 至,可以在存储过程或SQL 语句提交执行后马上观察 其执行进度,如果比较缓慢,则可以中断其执行,进行 调优,从而缩短调试周期,提高开发效率

以上就是关于oracle数据库创建好实例之后没有pfile和spfile文件夹怎么办全部的内容,包括:oracle数据库创建好实例之后没有pfile和spfile文件夹怎么办、配置归档日志,让数据库管理更加顺畅、oracle中的schema在哪个动态视图中可以查询到相关的信息等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

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

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

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

发表评论

登录后才能评论

评论列表(0条)

保存