作者:eygle
Oracle在数据库内部通过相应的算法转换来进行数据存储,本文简单介绍Oracle的Number型数值存储及转换.这个内容是为了回答留言板上的2119号问题.
我们可以通过DUMP函数来转换数字的存储形式,一个简单的输出类似如下格式:
SQL> select dump(1) from dual;
DUMP(1)
------------------
Typ=2 Len=2: 193,2
|
DUMP函数的输出格式类似:
类型 <[长度]>，符号/指数位 [数字1，数字2，数字3，......，数字20]
各位的含义如下:
1.类型: Number型,Type=2 (类型代码可以从Oracle的文档上查到)
2.长度:指存储的字节数
3.符号/指数位
在存储上,Oracle对正数和负数分别进行存储转换:
正数：加1存储(为了避免Null)
负数：被101减,如果总长度小于21个字节，最后加一个102(是为了排序的需要)
指数位换算:
正数：指数=符号/指数位 - 193 (最高位为1是代表正数)
负数：指数=62 - 第一字节
4.从<数字1>开始是有效的数据位
从<数字1>开始是最高有效位,所存储的数值计算方法为：
将下面计算的结果加起来：
每个<数字位>乘以100^(指数-N) (N是有效位数的顺序位，第一个有效位的N=0)
5. 举例说明
SQL> select dump(123456.789) from dual;
DUMP(123456.789)
-------------------------------
Typ=2 Len=6: 195,13,35,57,79,91
|
<指数>: 195 - 193 = 2
<数字1> 13 - 1 = 12 *100^(2-0) 120000
<数字2> 35 - 1 = 34 *100^(2-1) 3400
<数字3> 57 - 1 = 56 *100^(2-2) 56
<数字4> 79 - 1 = 78 *100^(2-3) .78
<数字5> 91 - 1 = 90 *100^(2-4) .009
123456.789
SQL> select dump(-123456.789) from dual;
DUMP(-123456.789)
----------------------------------
Typ=2 Len=7: 60,89,67,45,23,11,102
|
<指数> 62 - 60 = 2(最高位是0，代表为负数)
<数字1> 101 - 89 = 12 *100^(2-0) 120000
<数字2> 101 - 67 = 34 *100^(2-1) 3400
<数字3> 101 - 45 = 56 *100^(2-2) 56
<数字4> 101 - 23 = 78 *100^(2-3) .78
<数字5> 101 - 11 = 90 *100^(2-4) .009
123456.789(-)
现在再考虑一下为什么在最后加102是为了排序的需要，-123456.789在数据库中实际存储为
60,89,67,45,23,11
而-123456.78901在数据库中实际存储为
60,89,67,45,23,11,91
可见，如果不在最后加上102，在排序时会出现-123456.789<-123456.78901的情况。
对于2119号提问,第一个问题是:
1.请问为什么193,2各代表什么意思？
从上面就可以看到答案了.
2.还有NUMBER数字类型为什么有2个字节的长度呢？
对于这个问题,我想我们应该知道,所有数据类型最终在计算机里都以二进制存储,实际上所谓的数据类型都是我们定义的.所以存储只由算法决定.
所以这个问题是不成立的.比如:
SQL> select dump(110) from dual;
DUMP(110)
---------------------
Typ=2 Len=3: 194,2,11
SQL> select dump(1100) from dual;
DUMP(1100)
-------------------
Typ=2 Len=2: 194,12
|
我们会看到,虽然1100>110,但是存储上1100却只占2字节,而110却占了3个字节.
Posted by eygle at 1:54 PM
| Comments (3)
December 10, 2005
作者:eygle
夏天去黄山的时候,带了几种茶回来,其中一种就是太平猴魁.最近一直在喝的就是这种茶.
太平猴魁名列中国十大绿茶之列。属绿茶类尖茶，为我国“尖茶之冠”。尖茶特点是叶芽挺直肥实，两头尖而不翘，不弓弯、不松散。
太平猴魁产于安徽省太平县猴坑、凤凰山、狮彤山、鸡公山、鸡公尖一带，其中以猴坑所产质量最为上乘。这里依山濒水，林茂景秀，湖光山色交融映辉。茶园多分布在25~40度的山坡上,具有得天独厚的生态环境。这里年平均温度14~15℃，年平均降水量1650~2000毫米，土壤多为千枝岩、花岗岩风化而成的乌沙土，土层深厚肥沃，通气透水性好，茶树生长良好，芽肥叶壮，持嫩性强。当地茶树品种90%以上为柿大茶。这是个分枝稀、节间短、叶片大、色泽绿、茸毛多的品种，适制猴魁的良种资源。太平猴魁为尖茶之极品。
太平猴魁的鲜叶采摘特别讲究，谷雨前后，当20%芽梢长到一芽三叶初展时，即可开园。其后3~4天采一批，采到立夏停采。采摘标准为一芽三叶初展，采回的鲜叶要进行“拣尖”，即折下一芽带二叶的“尖头”，作为制猴魁的原料。“尖头”要求芽叶肥壮，匀齐整枝，老嫩适度，叶缘背卷，且芽尖和叶尖长度相齐，以保证成茶能形成“二叶抱一芽”的外形。采摘要在晴天进行，雨天一般不采。一般上午采、中午拣，当天制完。制造分杀青、毛烘、足烘、复焙四道工序。该茶制法不经揉捻，茶汁未出，故极耐冲泡。
太平猴魁的外形是两叶抱芽，平扁挺直，自然舒展，白毫隐伏，有“猴魁两头尖，不散不翘不卷边”之称。叶色苍绿匀润，叶脉绿中隐红，俗称“红丝线”。花香高爽，滋味甘醇，有独特的“猴韵”。汤色清绿明净，叶底嫩绿匀亮，芽叶成朵肥壮。品饮时，可体会出“头泡香高，二泡味浓，三泡四泡幽香犹存”的意境。 高香醇味，回味鲜甘，汤色清澈，叶底黄嫩。 猴魁茶共分猴魁、魁尖、尖茶一至五级共七级，以猴魁为首。
由于猴坑所产魁尖风格独特，质量超群，使其他产地魁尖望尘莫及，特冠以猴坑地名，叫“猴魁”。
Posted by eygle at 11:33 AM
| Comments (1)
December 9, 2005
作者:eygle
今天EMC的磁盘又坏了一块.
# navicli -h 172.16.9.5 getdisk 0_1_10
Bus 0 Enclosure 1 Disk 10
State: Removed
|
热备盘顶上:
# navicli -h 172.16.9.5 getdisk 0_1_14
Bus 0 Enclosure 1 Disk 14
Vendor Id: SEAGATE
Product Id: ST314680 CLAR72
Product Revision: 7A0A
Lun: 103
Type: 103: Hot Spare
State: Enabled
Hot Spare: 103: YES
Hot Spare Replacing: 0_1_10
Prct Rebuilt: 103: 100
Prct Bound: 103: 100
Serial Number: 3HY6V5CZ
Sectors: 139681792 (68204)
Capacity: 68238
Private: 103: 69704
Bind Signature: 0x65b4, 1, 14
Hard Read Errors: 0
Hard Write Errors: 0
Soft Read Errors: 2
Soft Write Errors: 2
Read Retries: N/A
Write Retries: N/A
Remapped Sectors: N/A
Number of Reads: 92936711
Number of Writes: 7132867
Number of Luns: 1
Raid Group ID: 103
Clariion Part Number: DG118032458
Request Service Time: N/A
Read Requests: 92936711
Write Requests: 7132867
Kbytes Read: 741072014
Kbytes Written: 128996672
Stripe Boundary Crossing: 0
|
更换之后:
# navicli -h 172.16.9.5 getdisk 0_1_10
Bus 0 Enclosure 1 Disk 10
Vendor Id: SEAGATE
Product Id: ST373307 CLAR72
Product Revision: 7A10
Lun: 19
Type: 19: RAID5
State: Enabled
Hot Spare: 19: NO
Prct Rebuilt: 19: 100
Prct Bound: 19: 100
Serial Number: 3HZY6WL2
Sectors: 139681792 (68204)
Capacity: 68238
Private: 19: 69704
Bind Signature: 0x13cf, 1, 10
Hard Read Errors: 0
Hard Write Errors: 0
Soft Read Errors: 2
Soft Write Errors: 2
Read Retries: N/A
Write Retries: N/A
Remapped Sectors: N/A
Number of Reads: 92982711
Number of Writes: 7429955
Number of Luns: 1
Raid Group ID: 11
Clariion Part Number: DG118032459
Request Service Time: N/A
Read Requests: 92982711
Write Requests: 7429955
Kbytes Read: 742887422
Kbytes Written: 199290063
Stripe Boundary Crossing: 71209229
|
热备盘释放:
# navicli -h 172.16.9.5 getdisk 0_1_14
Bus 0 Enclosure 1 Disk 14
Vendor Id: SEAGATE
Product Id: ST314680 CLAR72
Product Revision: 7A0A
Lun: 103
Type: 103: Hot Spare
State: Hot Spare Ready
Hot Spare: 103: YES
Hot Spare Replacing: Inactive
Prct Rebuilt: 103: 100
Prct Bound: 103: 100
Serial Number: 3HY6V5CZ
Sectors: 139681792 (68204)
Capacity: 68238
Private: 103: 69704
Bind Signature: 0x65b4, 1, 14
Hard Read Errors: 0
Hard Write Errors: 0
Soft Read Errors: 0
Soft Write Errors: 0
Read Retries: N/A
Write Retries: N/A
Remapped Sectors: N/A
Number of Reads: 1614352
Number of Writes: 2259175
Number of Luns: 1
Raid Group ID: 103
Clariion Part Number: DG118032458
Request Service Time: N/A
Read Requests: 1614352
Write Requests: 2259175
Kbytes Read: 204060088
Kbytes Written: 141007522
Stripe Boundary Crossing: 0
|
Posted by eygle at 4:44 PM
| Comments (0)
作者:eygle
Oracle在10g中引入了闪回区(flash recovery area)的概念，用以简化和完善备份，但是闪回区同样需要精心规划和设置，否则一样会遇到问题，从Oracle10gR2开始，Oracle还提供了一个新的视图V$FLASH_RECOVERY_AREA_USAGE，用以监控闪回区空间的耗用情况。本文简要介绍Oracle闪回区的警报和空间维护机制。
每次RMAN在闪回区(flash recovery area)创建文件时，会同时更新可删除文件列表。当闪回区存在空间压力时，Oracle会自动从闪回区中删除废弃文件，当没有更多空间可以释放时，Oracle会给出空间压力警报。
当空间使用达到100%，数据库将会因为无法归档等原因挂起。
闪回区的大小由:db_recovery_file_dest_size 参数指定。
路径由: db_recovery_file_dest 参赛指定。
SQL> show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 65G
|
这两个参数都是动态参数。
当闪回区空间使用达到85%时，Oracle会发出警告:
*** SERVICE NAME:(SYS$BACKGROUND) 2005-12-03 13:20:16.864
*** SESSION ID:(156.1) 2005-12-03 13:20:16.864
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 85.00% used,
and has 8050696704 remaining bytes available.
|
当空间使用达到97%的时候，Oracle会发出Critical的警报:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 97.02% used,
and has 1602355712 remaining bytes available.
|
当空间使用达到100%的时候，数据库无法归档就会挂起了:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used,
and has 0 remaining bytes available.
|
接下来就是这样的错误了:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 9563136 bytes disk space from 53687091200 limit
*** 2005-12-04 13:59:14.011 52278 kcrr.c
ARC1: Error 19809 Creating archive log file to
'/msflsh/MMSDB/archivelog/2005_12_04/o1_mf_1_17108_%u_.arc'
*** 2005-12-04 13:59:14.011 50725 kcrr.c
kcrrfail: dest:10 err:19809 force:0 blast:1
*** 2005-12-04 13:59:14.012 52278 kcrr.c
ARC1: All standby destinations failed; successful archival assumed
*** 2005-12-04 13:59:14.026 16432 kcrr.c
ORA-16038: log 1 sequence# 17108 cannot be archived
|
注意这里的一个词:reclaim,Oracle用了回收在这里，意思就是已经没有空间可以回收以满足归档的空间需求了。
当Oracle在reclaim空间时，你可能看到如下类似信息:
Sat Oct 1 21:20:54 2005
Deleted Oracle managed file +ORADG/danaly/backupset/2006_09_07/ncsnf0_tag20060907t192619_0.274
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_35.276.600588049
Sun Oct 2 05:46:40 2005
Thread 1 advanced to log sequence 80
Current log# 2 seq# 80 mem# 0: +ORADG/danaly/onlinelog/group_2.260.600173851
Current log# 2 seq# 80 mem# 1: +ORADG/danaly/onlinelog/group_2.261.600173853
Sun Oct 2 05:46:41 2005
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_36.277.600600509
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_37.278.600625093
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_09/thread_1_seq_38.279.600674413
|
Posted by eygle at 4:19 PM
| Comments (4)
December 7, 2005
作者:eygle
在LGWR的trace文件中看到大量如下信息:
*** 2005-08-30 17:49:05.751
LGWR: Archivelog for thread 1 sequence 5068 will NOT be compressed
*** 2005-08-30 18:03:25.576
LGWR: Archivelog for thread 1 sequence 5069 will NOT be compressed
*** 2005-08-30 18:04:29.776
LGWR: Archivelog for thread 1 sequence 5070 will NOT be compressed
*** 2005-08-30 18:05:26.771
LGWR: Archivelog for thread 1 sequence 5071 will NOT be compressed
*** 2005-08-30 18:06:24.778
LGWR: Archivelog for thread 1 sequence 5072 will NOT be compressed
*** 2005-08-30 18:07:20.655
LGWR: Archivelog for thread 1 sequence 5073 will NOT be compressed
*** 2005-08-30 18:08:29.228
LGWR: Archivelog for thread 1 sequence 5074 will NOT be compressed
...
|
Oracle给出的解释是:
These informational messages do not indicate any problem and are reported
in 10.1.0.X regardless of database configuration and specific settings.
在Oracle10.1.0.X中，这些信息不表明任何故障及数据库设置问题。
Archivelog compression is not available in 10gR1.
归档日志压缩特性在10gR1中尚不可用。
从这些解释中，我们可以看到，Oracle在不同的软件发布版本中，已经开始加入未公布的功能或特性。
而这些特性可能有待进一步完善，甚至可能在将来的版本中被取消。
在10gR2中，我们仍然没有看到Archivelog Compression的特性，但是Rman的备份集压缩功能自Oracle10gR1已经被引入。
迟早Oracle会为我们带来Archivelog Compression 的功能，这些简单的错误信息给我们透漏了Oracle变革的步伐。
加上Oracle9iR2引入的压缩表(COMPRESS TABLE)功能，以及此前的压缩索引的功能,Oracle不断的在各个部位引入Compression特性，以减少空间耗用，在这条路上Oracle一定会走得更远。
那么，问题是还有什么是可以压缩的呢?
Posted by eygle at 11:47 AM
| Comments (1)
作者:eygle
前面曾经发过一篇招聘DBA的Blog,后来飞走了一个满意的人选,所以现在,我不得不继续开始寻找,希望有兴趣的朋友继续发简历给我,接受简历的信箱为:
eygle.com@gmail.com
具体可以参考我前面的Blog.谢谢大家!
Posted by eygle at 11:25 AM
| Comments (2)
December 6, 2005
作者:eygle
由于日志切换过于频繁,今天调整了一下日志文件大小,数据库为Oracle10g 10.1.0.3.0.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - 64bi
PL/SQL Release 10.1.0.3.0 - Production
CORE 10.1.0.3.0 Production
TNS for Solaris: Version 10.1.0.3.0 - Production
NLSRTL Version 10.1.0.3.0 - Production
|
调整步骤如下:
SQL> col member for a50
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS
---------- ------- ------- ---------------------------------------- ---
3 ONLINE +DATADG/mmsdb/onlinelog/group_3.274.1 NO
3 ONLINE +DATADG/mmsdb/onlinelog/group_3.275.1 NO
2 ONLINE +DATADG/mmsdb/onlinelog/group_2.272.1 NO
2 ONLINE +DATADG/mmsdb/onlinelog/group_2.273.1 NO
1 ONLINE +DATADG/mmsdb/onlinelog/group_1.270.1 NO
1 ONLINE +DATADG/mmsdb/onlinelog/group_1.271.1 NO
1 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_1_15dbl80x_.log YES
2 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_2_15dbl8l1_.log YES
3 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_3_15dbl93s_.log YES
9 rows selected.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
-------- ---------- ---------- ---------- ---------- --- ---------- ------------- ------------
1 1 17717 10485760 3 NO CURRENT 178164478 06-DEC-05
2 1 17715 10485760 3 YES INACTIVE 178137459 06-DEC-05
3 1 17716 10485760 3 YES ACTIVE 178149970 06-DEC-05
SQL> alter database add logfile group 4 size 30m;
Database altered.
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- -------------------------------------------------- ---
3 ONLINE +DATADG/mmsdb/onlinelog/group_3.274.1 NO
3 ONLINE +DATADG/mmsdb/onlinelog/group_3.275.1 NO
2 ONLINE +DATADG/mmsdb/onlinelog/group_2.272.1 NO
2 ONLINE +DATADG/mmsdb/onlinelog/group_2.273.1 NO
1 ONLINE +DATADG/mmsdb/onlinelog/group_1.270.1 NO
1 ONLINE +DATADG/mmsdb/onlinelog/group_1.271.1 NO
1 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_1_15dbl80x_.log YES
2 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_2_15dbl8l1_.log YES
3 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_3_15dbl93s_.log YES
4 ONLINE +DATADG/mmsdb/onlinelog/group_4.291.1 NO
4 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_4_1s9yx01j_.log YES
11 rows selected.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------- ------------- ------------
1 1 17759 10485760 3 YES INACTIVE 178672877 06-DEC-05
2 1 17760 10485760 3 YES INACTIVE 178683645 06-DEC-05
3 1 17761 10485760 3 YES ACTIVE 178694045 06-DEC-05
4 1 17762 31457280 2 NO CURRENT 178703002 06-DEC-05
SQL> alter database drop logfile group 2;
Database altered.
SQL> alter database add logfile group 2 size 30m;
Database altered.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ----------- ------------- -----------
1 1 17759 10485760 3 YES INACTIVE 178672877 06-DEC-05
2 1 0 31457280 2 YES UNUSED 0
3 1 17761 10485760 3 YES INACTIVE 178694045 06-DEC-05
4 1 17762 31457280 2 NO CURRENT 178703002 06-DEC-05
SQL> alter database drop logfile group 3;
Database altered.
SQL> alter database add logfile group 3 size 30m;
Database altered.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- --------- ------------- ------------
1 1 17759 10485760 3 YES INACTIVE 178672877 06-DEC-05
2 1 0 31457280 2 YES UNUSED 0
3 1 0 31457280 2 YES UNUSED 0
4 1 17762 31457280 2 NO CURRENT 178703002 06-DEC-05
SQL> alter database drop logfile group 1;
Database altered.
SQL> alter database add logfile group 1 size 30m;
Database altered.
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- -------------------------------------------------- ---
3 ONLINE +DATADG/mmsdb/onlinelog/group_3.275.3 NO
3 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_3_1s9z8pb6_.log YES
2 ONLINE +DATADG/mmsdb/onlinelog/group_2.273.3 NO
2 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_2_1s9yzv0f_.log YES
1 ONLINE +DATADG/mmsdb/onlinelog/group_1.271.3 NO
1 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_1_1s9z9rpy_.log YES
4 ONLINE +DATADG/mmsdb/onlinelog/group_4.291.1 NO
4 ONLINE /msflsh/MMSDB/onlinelog/o1_mf_4_1s9yx01j_.log YES
8 rows selected.
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------- ------------- ------------
1 1 0 31457280 2 YES UNUSED 0
2 1 0 31457280 2 YES UNUSED 0
3 1 0 31457280 2 YES UNUSED 0
4 1 17762 31457280 2 NO CURRENT 178703002 06-DEC-05
|
Ok,现在开始提问,在以上的输出中,你可以指出多少个知识点?
如果我就以上输出来提问,会有多少知识是你不知道的?
Posted by eygle at 4:28 PM
| Comments (16)
December 5, 2005
作者:eygle
下班的时候,想不到又遇到了ORA-19815错误,这个10g的数据库最近数据量狂增,每天产生大约5~6个G的归档:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 85.00% used,
and has 8052259328 remaining bytes available.
*************************************************************
You have the following choices to free up space fromflash recovery area:1. Consider changing your RMAN retention policy. If you are using dataguard, then consider changing your RMAN archivelog deletion policy.2. Backup files to tertiary device such as tape using the RMAN command BACKUP RECOVERY AREA.3. Add disk space and increase the db_recovery_file_dest_size parameter to reflect the new space.4. Delete unncessary files using the RMAN DELETE command. If an OS command was used to delete files, then use RMAN CROSSCHECK and DELETE EXPIRED commands.
db_recovery_file_dest_size设置的是50G,在当前的备份策略下已经不足够.只好临时扩展一下恢复区:
SQL> show parameter recov
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 50G
recovery_parallelism integer 0
SQL> alter system set db_recovery_file_dest_size=65G scope=both;
System altered.
SQL> show parameter recov
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 65G
recovery_parallelism integer 0
|
再修改下冗余策略,释放部分磁盘空间:
$ rman target /
Recovery Manager: Release 10.1.0.3.0 - 64bit Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
connected to target database: MMSDB (DBID=799462343)
RMAN> show all;
using target database controlfile instead of recovery catalog
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
....
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
new RMAN configuration parameters are successfully stored
RMAN> delete obsolete;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=127 devtype=DISK
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set 672 27-NOV-05
Backup Piece 672 27-NOV-05
/msflsh/MMSDB/backupset/2005_11_27/o1_mf_annnn_TAG20051127T043004_1rkkggjh_.bkp
Backup Set 673 27-NOV-05
Backup Piece 673 27-NOV-05
/msflsh/MMSDB/backupset/2005_11_27/o1_mf_annnn_TAG20051127T043004_1rkkh05d_.bkp
Backup Set 674 27-NOV-05
Backup Piece 674 27-NOV-05
/msflsh/MMSDB/backupset/2005_11_27/o1_mf_annnn_TAG20051127T043004_1rkkhvtb_.bkp
Backup Set 676 28-NOV-05
Backup Piece 676 28-NOV-05
/msflsh/MMSDB/backupset/2005_11_28/o1_mf_annnn_TAG20051128T043004_1rn5tfoo_.bkp
Backup Set 718 03-DEC-05
Backup Piece 718 03-DEC-05
/msflsh/MMSDB/autobackup/2005_12_03/o1_mf_s_576045489_1s1d5kgd_.bkp
Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=/msflsh/MMSDB/backupset/2005_11_27/
o1_mf_annnn_TAG20051127T043004_1rkkggjh_.bkp recid=672 stamp=575440206
deleted backup piece
backup piece handle=/msflsh/MMSDB/backupset/2005_11_27/
o1_mf_annnn_TAG20051127T043004_1rkkh05d_.bkp recid=673 stamp=575440224
deleted backup piece
backup piece handle=/msflsh/MMSDB/backupset/2005_11_27/
o1_mf_annnn_TAG20051127T043004_1rkkhvtb_.bkp recid=674 stamp=575440251
deleted backup piece
backup piece handle=/msflsh/MMSDB/backupset/2005_11_28/
o1_mf_annnn_TAG20051128T043004_1rn5tfoo_.bkp recid=676 stamp=575526605
deleted backup piece
backup piece handle=/msflsh/MMSDB/autobackup/2005_12_03/
o1_mf_s_576045489_1s1d5kgd_.bkp recid=718 stamp=576045489
Deleted 5 objects
RMAN> exit
Recovery Manager complete.
|
赶快跑回家,北京冷的要命了,明天需要重新规划一下这个数据库了.以前的设计容量太小了.
Posted by eygle at 9:37 PM
| Comments (5)
December 4, 2005
作者:eygle
终于对铺天盖地的spam留言忍无可忍了,20条一批的删除也要删好久,今天花了点时间安装了anti-spam的优秀插件Scode,这一插件通过加入图片验证码可以有效的防止机器人回复,但是同时会给大家回复带来一点小负担,希望大家不要介意.
安装Scode需要Perl的GD模块支持,GD模块可以使用CPAN通过如下步骤安装:
perl -MCPAN -e shell
cpan> d /gd/
cpan> install L/LD/LDS/GD-2.30.tar.gz
之后安装SCODE插件就很顺利了.
Posted by eygle at 1:40 PM
| Comments (2)
作者:eygle
有朋友问到这样一个问题:如何远程判断Oracle数据库的安装平台.
我想到的一个方法是,通过查询v$version视图来得到:
1.Windows平台的输出
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
PL/SQL Release 9.2.0.6.0 - Production
CORE 9.2.0.6.0 Production
TNS for 32-bit Windows: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
2.Linux平台输出
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
3.Solaris平台的输出
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Solaris: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
4.AIX平台的输出(感谢brucewoo提供的AIX上输出)
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
PL/SQL Release 9.2.0.5.0 - Production
CORE 9.2.0.6.0 Production
TNS for IBM/AIX RISC System/6000: Version 9.2.0.5.0 - Production
NLSRTL Version 9.2.0.5.0 - Production
5.HPUX上的输出(感谢tom.shew的提供)
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
PL/SQL Release 9.2.0.6.0 - Production
CORE 9.2.0.6.0 Production
TNS for HPUX: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
Posted by eygle at 2:00 AM
| Comments (6)
