ora-16014,ora16016
oracle ORA-01840:输入值对于日期格式不够长，请高手帮忙。有非法数据？怎么处理？
oracle ORA-01840:输入值对于日期格式不够长，请高手帮忙。有非法数据？怎么处理？日期型数据内有不规范数据造成的。找出那条记录，UPDATE日期字段。
其具体的语法格式如下：
TRUNC（date,[fmt]）
其中：
date 为必要参数，是输入的一个日期值
fmt 参数可忽略，是日期格式，用以指定的元素格式来截去输入的日期值。忽略它则由最近的日期截去
下面是该函数的使用情况：
trunc(sysdate,'yyyy') --返回当年第一天.
trunc(sysdate,'mm') --返回当月第一天.
trunc(sysdate,'d') --返回当前星期的第一天.说明 你要输入的日期过短 ，可能要求输入日期的格式是‘yyyy-mm-dd hh24:mi:ss'
你就要输入 20130101125959 日期就变成 2013年1月1日12点59分59秒
如果你要看自己输入的结果 输入：
select to_char(to_date($rundate,'yyyymmddhh24miss’），‘yyyy-mm-dd hh24:mi:ss') from dual
linux oracle startup提示ORA-03113: end-of-file on communication channel错误
数据库开归档了 ？
如果没改过归档路径，检查下归档文件夹体积，是不是已经超5G了，手工清理下，或者在mount状态下，把db_recovery_file_dest_size这个参数改大一些。
oracle中出现016014错误怎么解决
1.问题以及解决过程
SQL select status from v$instance;
STATUS
------------
MOUNTED
SQL alter database open;
alter database open
*
第 1 行出现错误:
ORA-16014: 日志 2 的序列号 27 未归档, 没有可用的目的地
ORA-00312: 联机日志 2 线程 1:
'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG'
SQL show parameter db_recovery_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string D:\oracle\product\10.2.0/flash
_recovery_area
db_recovery_file_dest_size big integer 2G
SQL alter system archive log current;
alter system archive log current
*
第 1 行出现错误:
ORA-01109: 数据库未打开
SQL alter system switch logfile;
alter system switch logfile
*
第 1 行出现错误:
ORA-01109: 数据库未打开
SQL shutdown immediate;
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL startup
ORACLE 例程已经启动。
Total System Global Area 201326592 bytes
Fixed Size 1248092 bytes
Variable Size 88081572 bytes
Database Buffers 109051904 bytes
Redo Buffers 2945024 bytes
数据库装载完毕。
ORA-16038: 日志 2 序列号 27 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 2 线程 1:
'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG'
SQL alter database open;
alter database open
*
第 1 行出现错误:
ORA-16014: 日志 2 的序列号 27 未归档, 没有可用的目的地
ORA-00312: 联机日志 2 线程 1:
'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG'
SQL show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string D:\oracle\product\10.2.0/flash
_recovery_area
db_recovery_file_dest_size big integer 2G
SQL alter system set db_recovery_file_dest_size=3G scope=both;
系统已更改。
SQL alter database open;
数据库已更改。
2.反思：
(1).检查flash recovery area的使用情况：
SQL select * from v$flash_recovery_area_usage;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG 6.36 0 4
BACKUPPIECE .22 0 1
IMAGECOPY 63.68 0 5
FLASHBACKLOG .51 .25 2
已选择6行。
SQL
(2).计算flash recovery area已经占用的空间：
SQL select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;
SUM(PERCENT_SPACE_USED)*3/100
-----------------------------
2.1231
可以看到，这里已经有2.1231G使用了，这说明我们刚开始设置的db_recovery_file_dest_size=2G不足，导致 online redo log无法归档，在这里，我们通过设置db_recovery_file_dest_size参数，增大了flash recovery area来解决这个问题。
(3).也可以通过删除flash recovery area中不必要的备份来释放flash recovery area空间来解决这个问题：
(1). delete obsolete;
(2). crosscheck backupset;
delete expired backupset;
oracle查询报错：ora-01416: 两表无法彼此外部连接，是什么原因？
原因可能是 你用Oracle 的 （+） 方式 对两个表相互外联接了
首先 需要确认你的需求，是不是想要使用完全外连接，
如果是使用 ansi 的方式 FULL OUTER JOIN 进行外连接即可
如何删除控制文件中过去rman备份到磁带的备份集
RMAN delete noprompt obsolete;
......
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 02/10/2014 14:00:50
RMAN-06091: no channel allocated for maintenance (of an appropriate type)
rman 下list backup of database 发现有几个备份到磁带的备份集。
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
4943 838M SBT_TAPE 00:00:35 02/10/2014
BP Key: 4943 Status: UNAVAILABLE Tag: TAG20100411T004252
Piece Name: arch_20100411_4970_1
List of Archived Logs in backup set 4943
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 16014 4006475789091 10-APR-10 4006475846928 10-APR-10
1 16015 4006475846928 10-APR-10 4006475885650 10-APR-10
1 16016 4006475885650 10-APR-10 4006475943776 10-APR-10
1 16017 4006475943776 10-APR-10 4006475979118 10-APR-10
1 16018 4006475979118 10-APR-10 4006476023785 10-APR-10
1 16019 4006476023785 10-APR-10 4006476071180 10-APR-10
1 16020 4006476071180 10-APR-10 4006476158466 10-APR-10
1 16021 4006476158466 10-APR-10 4006476250848 10-APR-10
1 16022 4006476250848 10-APR-10 4006525513941 11-APR-10
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
4948 517M SBT_TAPE 00:00:29 02/10/2014
BP Key: 4948 Status: AVAILABLE Tag: TAG20100412T002657
Piece Name: arch_20100412_4976_1
List of Archived Logs in backup set 4948
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 16030 4006527200207 11-APR-10 4006527247642 11-APR-10
1 16031 4006527247642 11-APR-10 4006527316362 11-APR-10
1 16032 4006527316362 11-APR-10 4006527374966 11-APR-10
1 16033 4006527374966 11-APR-10 4006527472280 11-APR-10
1 16034 4006527472280 11-APR-10 4006528044006 11-APR-10
1 16035 4006528044006 11-APR-10 4006576257046 02/10/2014
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
且前一天备份的那个backupset也没有被删掉。
所以，至此问题清楚了，FRA使用率高是因为多了一个前一天的backupset 。
问题是，为什么命令块里面明明有
report obsolete;
CROSSCHECK BACKUP;
CROSSCHECK COPY;
DELETE noprompt EXPIRED BACKUP;
DELETE noprompt EXPIRED COPY;
delete noprompt obsolete;
这些命令，为什么没有把那个已经过期的备份集删掉呢？
于是，rman单独执行
RMAN delete noprompt obsolete;
......
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 02/10/2014 14:00:50
RMAN-06091: no channel allocated for maintenance (of an appropriate type)
同样不能删除。
这时候才反映过来，备份集删不掉应该是与控制文件中Device Type 为 SBT_TAPE 的东西有关。
这才想起年前放假前测试过一款备份软件，备份集已经没了，但是备份信息依然存在于控制文件中，正因为rman试图去删除
这些backup set 的时候发现 没有分配合适的通道，无法删除，所以导致FRA上expired 的backupset 也无法被成功删除。
所以现在问题就是怎样去把控制文件中的那些到磁带的备份信息删掉。
rman target /
RMAN show channel ;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name FINAPRIM are:
RMAN configuration has no stored or default parameters
没有已分配的渠道。
然后问题的关键是，现在已经没有磁带备份设备了，怎样去分配一个到磁带的渠道，幸运的是看到了一个兄弟类似的案例，
有这么一段：
Suppose your current backup strategy uses only disk, but you have several old tape
backups you want to get rid of. You can allocate a maintenance channel for performing the
deletion of the tape backups by using the dummy sbt API (because the media manager isn’t
available any longer). You can then use the delete obsolete command to remove the tape
backups. Here’s an example showing how to do those things:
RMAN allocate channel for maintenance device type sbt
parms 'SBT_LIBRARY=oracle.disksbt,
ENV=(BACKUP_DIR=/tmp)';
RMAN delete obsolete;
Although the media manager isn’t available any longer, RMAN simulates a callout to the
media management layer (MML) and successfully initiates the maintenance command to
delete the old tape backups you want toget rid of.
哈哈，看起来太合适我了。
RMAN allocate channel for maintenance device type sbt parms 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';
RMAN delete noprompt obsolete;
RMAN DELETE noprompt EXPIRED ;
RMAN release channel ;