精华内容
下载资源
问答
  • 我们知道Oracle10gR2以前的版本,如果使用RMAN恢复数据库,临时表空间的临时文件是不会自动恢复的。我们恢复完成之后有时忘记添加临时文件,这样导致应用出错时才能发现。 通过rman 恢复alert日志...

    我们知道在Oracle10gR2以前的版本中,如果使用RMAN恢复数据库,临时表空间的临时文件是不会自动恢复的。
    我们在恢复完成之后有时忘记添加临时文件,这样导致在应用中出错时才能发现。

    通过rman 恢复在alert日志中可以发现以下痕迹

    Wed May 07 11:57:59 2008
    ARC2: Archival started
    ARC0: STARTING ARCH PROCESSES COMPLETE
    ARC0: Becoming the heartbeat ARCH
    ARC2 started with pid=18, OS id=3652
    Wed May 07 11:57:59 2008
    SMON: enabling cache recovery
    Wed May 07 11:58:00 2008
    Successfully onlined Undo Tablespace 1.
    Wed May 07 11:58:00 2008
    SMON: enabling tx recovery
    Wed May 07 11:58:00 2008
    Re-creating tempfile D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_TEMP_4221RHM1_.TMP as D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\DATAFILE\O1_MF_TEMP_422B68PG_.TMP
    Database Characterset is ZHS16GBK
    replication_dependency_tracking turned off (no async multimaster replication found)
    Starting background process QMNC
    QMNC started with pid=19, OS id=1644
    Wed May 07 11:58:06 2008
    Completed: alter database open
    Wed May 07 11:58:08 2008
    db_recovery_file_dest_size of 2048 MB is 7.69% used. This is a
    user-specified limit on the amount of space that will be used by this
    database for recovery-related files, and does not reflect the amount of
    space available in the underlying filesystem or ASM diskgroup.

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7199859/viewspace-262768/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/7199859/viewspace-262768/

    展开全文
  • 故障现象:临时表空间不足的问题已经报错过3次,客户也烦了,前两次都是同事添加5G的数据文件,目前已经达到40G,占用临时表空间主要是distinct 和group by 以及Union all 表数据量200W左右,也不至于把40G的临时...
  • 故障现象:临时表空间不足的问题已经报错过3次,客户也烦了,前两次都是同事添加5G的数据文件,目前已经达到40G,占用临时表空间主要是distinct 和group by 以及Union all 表数据量200W左右,也不至于把40G的临时...

    故障现象:临时表空间不足的问题已经报错过3次,客户也烦了,前两次都是同事添加5G的数据文件,目前已经达到40G,占用临时表空间主要是distinct 和group by 以及Union all 表数据量在200W左右,也不至于把40G的临时表空间撑爆。

    原因分析:既然排序用不了这么多临时表空间应该是别的原因造成。

    从包含故障时间段的AWR报告中可以看出这一阶段DBtime蛮高的,并且sql execute elapsed time 竟然占到了99.43%,可以断定是SQL语句引起的。

     

    通过TOP SQL定位到出问题的SQL

     

    确认是以下SQL引起:

    select 'A',
    d.explanation, --金融机构标识码
    c.account_no, --交易账号
    to_date(a.batchentrydate, 'yyyy-mm-dd'), --发生日期
    c.currencycode, --币种
    SUM(decode(A.Creditdebit, 'C', a.transactionamount, 0)), --当日贷方发生额
    SUM(decode(A.Creditdebit, 'D', a.transactionamount, 0)), --当日借方发生额
    case
    when C.Currencycode = 'JPY' Then
    Round(c.Ccyledgerbalance, 0)
    else
    c.ccyledgerbalance
    End Balance, --账户余额
    --b.instcode instcode, --系统虚拟机构代号
    1 datastatus, --前台对应的数据状态
    c.account_no || c.currencycode || '2013-01-04',
    to_date('2013-01-04', 'yyyy-mm-dd')
    from df_cust C
    left join (select distinct ACCOUNTBRANCH,
    DESCRIPTION,
    MASTERNO,
    CURRENCYCODE,
    ACCOUNT_NUMBER,
    SEQNO,
    ACCT_CLASS_CODE,
    PRODUCTCODE,
    VALUEDT_YYYY,
    VALUEDT_MM,
    VALUEDT_DD,
    BATCHENTRYDATE,
    VALUEDT_YYYYMMDD,
    NARRATIONPOST,
    TRANSACTIONAMOUNT,
    CREDITDEBIT,
    ACCOUNTBRANCH1,
    SEGMENTCODE,
    REFERENCENUMBER,
    NARRATIONTRAN,
    BATCHNUMBER,
    GLDEPTID,
    ARMCODE,
    EXTREFNO,
    MAKERID,
    CHECKERID,
    CHANNELID,
    TRANSACTION_AMT_IN_USD,
    ACCSHORTNAME,
    ARMNAME,
    SEGNAME,
    TXNCODE,
    REVERSALFLAG,
    EBBSREFERENCE,
    TRANSTYPECODE,
    CUSTOMERRATE,
    ADVTREASURYFLAG,
    VA_FLAG
    from df_acmov_today
    where Creditdebit in ('C', 'D')) a on a.account_number =
    c.account_no
    Left Join Da_Mid_Acc_Gl_Dic D On D.Source = A.Accountbranch
    Where exists (select 1
    from acc.t_base_account b
    where b.account = c.account_no
    and b.currence_code = c.currencycode)
    and a.account_number is not null
    and c.account_no like '0%'
    group by d.explanation, --金融机构标识码
    c.account_no, --交易账号
    a.batchentrydate, --发生日期
    c.currencycode, --币种
    C.Ccyledgerbalance--系统机构代号

    观察并分析其执行计划,貌似也没有什么问题,因为df_acmov_today(200W左右数据)是每天都清空的,没有索引,全表扫描,nestloops也正常。

    但是在执行SQL语句时通过脚本监控临时表空间的使用情况,发现临时表空间使用率很快就达到了40G左右。又要临时表空间不足了…

    使用dbms_stats.gather_table_stats 分析了下表,然后再去执行语句,发现很快。这下问题清楚了,SQL执行计划错误导致的问题。

    在对比下先前的SQL执行计划,发现在执行计划中基数不对,竟然为1 ,估算的差距太大了。

    为什么每天做分析的表(crontab job)最后执行计划却不对?

    最后竟然是这样:使用crontab 在凌晨2:30对表做分析,但是早上6点。其他任务对表做了,truncate 和Insert into 从而导致该原因。

    最终调整计划任务时间问题完全解决。

    展开全文
  • 客户是添加临时表空间数据文件时,不小心 ADD 到了文件系统,然后发现,后悔了,还OS层面 RM 了,重建调整吧。 实验就拿着普通的用户表空间练手吧。 目录 1. 创建用户表空间 2. 故意添加错误路径的数据...

    前提:非TEMP、UNDO和SYSTEM表空间,这仨是大爷,您得搂着点。来自博客园AskScuti 。客户是添加临时表空间数据文件时,不小心 ADD 到了文件系统中,然后发现,后悔了,还在OS层面 RM 了,重建调整吧。

    实验就拿着普通的用户表空间练手吧。

    目录

    1. 创建用户表空间

    2. 故意添加错误路径的数据文件

    3. 查询报错

    4. 表空间脱机

    5. 通过RMAN进行COPY

    6. 数据文件重命名

    7. 数据文件RECOVER

    8. 表空间联机

     

    1. 创建用户表空间

    SQL> create tablespace henry datafile '+ASMDATA' size 1m;
    
    Tablespace created.
    
    SQL> select name from v$datafile;
    
    NAME
    -------------------------------------------------------
    +ASMSYSTEM/racerp/datafile/system.260.1005224067
    +ASMSYSTEM/racerp/datafile/sysaux.261.1005224093
    +ASMSYSTEM/racerp/datafile/undotbs1.262.1005224115
    +ASMSYSTEM/racerp/datafile/undotbs2.264.1005224141
    +ASMSYSTEM/racerp/datafile/users.265.1005224147
    +ASMDATA/racerp/datafile/test.256.1005234027
    +ASMDATA/racerp/datafile/henry.257.1010151449

    2. 故意添加错误路径的数据文件

    SQL> alter tablespace henry add datafile '/u01/app/oracle/henry02.dbf' size 1m;
    
    Tablespace altered.
    
    SQL> select name from v$datafile;
    
    NAME
    -------------------------------------------------------
    +ASMSYSTEM/racerp/datafile/system.260.1005224067
    +ASMSYSTEM/racerp/datafile/sysaux.261.1005224093
    +ASMSYSTEM/racerp/datafile/undotbs1.262.1005224115
    +ASMSYSTEM/racerp/datafile/undotbs2.264.1005224141
    +ASMSYSTEM/racerp/datafile/users.265.1005224147
    +ASMDATA/racerp/datafile/test.256.1005234027
    +ASMDATA/racerp/datafile/henry.257.1010151449
    /u01/app/oracle/henry02.dbf

    3. 查询报错

    SQL> select tablespace_name,file_id from dba_temp_files;
    select tablespace_name,file_id from dba_temp_files
    *
    ERROR at line 1:
    ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
    ORA-01110: data file 201: '/u01/app/oracle/henry02.dbf'

    发现路径错了。

    4. 表空间脱机

    SQL> alter tablespace henry offline;
    
    Tablespace altered.

    5. 通过RMAN进行COPY

    [oracle@erpn2:/home/oracle]$rman target /
    
    Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jun 5 13:45:31 2019
    
    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
    
    connected to target database: RACERP (DBID=1820589684)
    
    RMAN> copy datafile '/u01/app/oracle/henry02.dbf' to '+ASMDATA';
    
    Starting backup at 2019-06-05 13:45:33
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=16 instance=RACERP_2 device type=DISK
    channel ORA_DISK_1: starting datafile copy
    input datafile file number=00008 name=/u01/app/oracle/henry02.dbf
    output file name=+ASMDATA/racerp/datafile/henry.261.1010151935 tag=TAG20190605T134535 RECID=4 STAMP=1010151935
    channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
    Finished backup at 2019-06-05 13:45:36
    
    Starting Control File and SPFILE Autobackup at 2019-06-05 13:45:36
    piece handle=/backup/RACERP_c-1820589684-20190605-03.ctl comment=NONE
    Finished Control File and SPFILE Autobackup at 2019-06-05 13:45:43

    6. 数据文件重命名

    SQL> alter database rename file '/u01/app/oracle/henry02.dbf' to '+ASMDATA/racerp/datafile/henry.261.1010151935';
    
    Database altered.

    7. 数据文件RECOVER

    SQL> recover datafile 8;
    Media recovery complete.

    8. 表空间联机

    SQL> alter tablespace henry online;
    
    Tablespace altered.
    
    SQL> select name from v$datafile;
    
    NAME
    ------------------------------------------------------
    +ASMSYSTEM/racerp/datafile/system.260.1005224067
    +ASMSYSTEM/racerp/datafile/sysaux.261.1005224093
    +ASMSYSTEM/racerp/datafile/undotbs1.262.1005224115
    +ASMSYSTEM/racerp/datafile/undotbs2.264.1005224141
    +ASMSYSTEM/racerp/datafile/users.265.1005224147
    +ASMDATA/racerp/datafile/test.256.1005234027
    +ASMDATA/racerp/datafile/henry.257.1010151449
    +ASMDATA/racerp/datafile/henry.261.1010151935

    转载于:https://www.cnblogs.com/askscuti/p/10979354.html

    展开全文
  • 临时文件损坏

    2018-08-02 11:18:00
    临时数据文件的损坏或丢失会造成需要使用临时表空间的命令执行失败,但不会造成实例崩溃。由于临时表空间存放的是临时数据,rman不会对其...A、向临时表空间中添加新的临时数据文件 SQL> alter tablespace temp ...

       临时数据文件的损坏或丢失会造成需要使用临时表空间的命令执行失败,但不会造成实例崩溃。由于临时表空间存放的是临时数据,rman不会对其进行备份,一旦损坏采用的恢复方法是重建或替换。

       如果在数据库运行过程中,发现临时数据文件损坏或丢失,可以采用替换的方法恢复,不需要重启数据库:

    A、   向临时表空间中添加新的临时数据文件

    SQL> alter tablespace temp add tempfile '/u01/app/oracle/oradata/orcl/temp02.dbf' size 100M;

    B、    删除掉损坏的临时文件

    SQL> alter tablespace temp drop tempfile '/u01/app/oracle/oradata/orcl/temp01.dbf';

    Tablespace altered.

     

    转载于:https://www.cnblogs.com/liang545621/p/9406057.html

    展开全文
  • 我们知道Oracle10gR2以前的版本,如果使用RMAN恢复数据库,临时表空间的临时文件是不会自动恢复的。这曾经引发了一系列的麻烦,很多DBA恢复完成之后忘记添加临时文件,经常到应用出错时才能发现。 ...
  • 通常来说如果出现该错误是由于临时表空间空间不足所致,只要给表空间添加数据文件就能解决问题(alter tablespace ts_name add tempfile file_name size n M)。当然最好是检查应用程序的设计,以优化排序操作。  但...
  • 通常来说如果出现该错误是由于临时表空间空间不足所致,只要给表空间添加数据文件就能解决问题(alter tablespace ts_name add tempfile file_name size n M)。当然最好是检查应用程序的设计,以优化排序操作。 但...
  • 今天对数据库做异机恢复,我们知道恢复过程是不对临时表空间进行恢复的,所以进行resetlogs打开数据库之后,需要对临时表空间进行处理,处理方式如下: 1 添加新的临时表空间文件。 2 删除旧的临时表空间...
  • 扩容oracle表空间脚本

    2019-08-09 12:59:28
    运维过程隔段时间会出现核心数据表空间和 临时表空间满导致数据库崩溃的情况发生,未避免发生类似情况编写检测表空间使用情况,配合计划任务超过一定比例后自动扩容。TEMP表空间不建议自扩展,而数据文件因数量...
  • 18->数据文件损坏修复

    2017-04-26 17:02:00
    1.数据文件恢复原理: 由于数据的修改会体现联机重做日志 所以数据可以通过重做日志恢复到数据文件中 ...添加一个表空间和临时表空间 并且创建一个用户 指定该表空间和默认表空间 create tablespace mydata d...
  • 数据库添加新用户

    2013-03-12 11:50:56
    1.如果PL/SQL 等工具里打开的话,直接修改下面的代码[斜体加粗部分]执行 2.确保路径存在,比如【E:\.../*第1步:创建临时表空间 */ create temporary tablespace user_temp tempfile 'D:\oracle\orada
  • 索引因历史原因都放在初始的索引表空间里,导致索引表空间不断添加数据文件。 再加上历史数据的归档,索引从来没维护过。 就想把大的索引维护下...个人理解:alter index rebuild online会在临时表空间中创建索引...
  • ocp原厂培训笔记(第七天)

    千次阅读 2009-09-25 15:14:00
    察看 临时文件临时文件丢失了,怎么解决:可以重新添加新的临时文件,或者直接通过多个临时表空间组成临时表空间组(这是10g 的新特性),如果某一个临时表空间丢了,oracle 会从组里自动找个可用的代替。LOG 日志组从...
  • MYSQL中文手册

    2013-03-11 21:21:34
    同一个数据库创建多个的缺陷 7.5. 优化MySQL服务器 7.5.1. 系统因素和启动参数的调节 7.5.2. 调节服务器参数 7.5.3. 控制查询优化器的性能 7.5.4. 编译和链接怎样影响MySQL的速度 7.5.5. MySQL如何使用...
  • MySQL 5.1中文手冊

    2009-12-11 09:43:12
    15.2.5. 创建InnoDB表空间 15.2.6. 创建InnoDB表 15.2.7. 添加和删除InnoDB数据和日志文件 15.2.8. InnoDB数据库的备份和恢复 15.2.9. 将InnoDB数据库移到另一台机器上 15.2.10. InnoDB事务模型和锁定 15.2.11. ...
  • 15.2.5. 创建InnoDB表空间 15.2.6. 创建InnoDB表 15.2.7. 添加和删除InnoDB数据和日志文件 15.2.8. InnoDB数据库的备份和恢复 15.2.9. 将InnoDB数据库移到另一台机器上 15.2.10. InnoDB事务模型和锁定 15.2.11. ...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 Oracle进程简介  9.2 ...
  • mysql5.1中文手册

    2008-01-09 09:54:20
    同一个数据库创建多个的缺陷 7.5. 优化MySQL服务器 7.5.1. 系统因素和启动参数的调节 7.5.2. 调节服务器参数 7.5.3. 控制查询优化器的性能 7.5.4. 编译和链接怎样影响MySQL的速度 7.5.5. ...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 oracle进程简介  9.2 ...
  • 同一个数据库创建多个的缺陷 7.5. 优化MySQL服务器 7.5.1. 系统因素和启动参数的调节 7.5.2. 调节服务器参数 7.5.3. 控制查询优化器的性能 7.5.4. 编译和链接怎样影响MySQL的速度 7.5.5. MySQL如何使用内存 ...
  •  6.6.4 查询临时表空间中临时文件的信息  6.6.5 查询表空间的空闲空间大小  6.6.6 查询数据段信息  6.7 OEM中管理表空间  6.7.1 创建(永久)表空间  6.7.2 扩展表空间  6.7.3 修改表空间的空间使用...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 oracle进程简介  9.2 ...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 oracle进程简介  9.2 ...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 oracle进程简介  9.2 ...
  •  8.4.2 临时表空间管理 与疑难解析  8.4.3 回滚表空间管理 与疑难解析 8.5 数据文件管理 与疑难解析  8.5.1 数据文件管理  8.5.2 数据文件管理疑难解析  第9章 进程管理  9.1 oracle进程简介  9.2 ...

空空如也

空空如也

1 2 3 4 5 ... 12
收藏数 237
精华内容 94
关键字:

在临时表空间中添加临时文件