[20150113]系统管理表空间的疑问2.txt

简介: [20150113]系统管理表空间的疑问2.txt --昨天探究系统管理表空间位图区分布的问题。 --自己得到一些结论: http://blog.itpub.net/267265/viewspace-1399275/ 总结: 1.使用系统管理表空间,位图区不仅仅在块开始的2-8块(10g)。

[20150113]系统管理表空间的疑问2.txt

--昨天探究系统管理表空间位图区分布的问题。
--自己得到一些结论:

http://blog.itpub.net/267265/viewspace-1399275/

总结:
1.使用系统管理表空间,位图区不仅仅在块开始的2-8块(10g)。11g没有问题,因为11g数据文件前面128块保留。
2.位图区除了位图信息,还有其他一些信息.
3.如果前面的位图区不够满足需要,从block=2的tail+1作为位图区
4.如果数据文件改变大小,如果尾部存在位图区,会出现位图区移动的情况(除非你仅仅改变减少增加几个块,这个留给大家测试)。
5.改变减少增加几个块,可能出现位图重叠的问题,出现ORA-03215错误。

$ oerr ora 3215
03215, 00000, "File Size specified for resize is too small "
// *Cause: File Size specified for resize datafile/tempfile causes
//         bitmap control structures to overlap
// *Action: Increase the specification for file size

--我当时还得到一个结论,如果设置
文件大小改变:
ALTER DATABASE DATAFILE 54 RESIZE 33554392K;
--这样后面的3个块正好够放余下的位图区,需要3块,位于块4194297,4194298,4194299。


--当前情况如下:
ALTER DATABASE DATAFILE 54 RESIZE 33554320K;
alter system dump datafile 54  block  2;

Start dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2
buffer tsn: 18 rdba: 0x0d800002 (54/2)
scn: 0x0002.db19fc66 seq: 0x01 flg: 0x04 tail: 0xfc661d01
frmt: 0x02 chkval: 0x90bf type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000001B0F3400 to 0x000000001B0F5400
01B0F3400 0000A21D 0D800002 DB19FC66 04010002  [........f.......]
01B0F3410 000090BF 00000036 00000008 003FFFF2  [....6.........?.]
01B0F3420 00000001 00000000 00000000 00000007  [................]
01B0F3430 003FFFE8 00000000 000002CC 00000000  [..?.............]
01B0F3440 00000000 00000000 00000000 00000000  [................]
01B0F3450 003FFFE9 00000003 00000000 00000000  [..?.............]
01B0F3460 00000000 00000000 00000000 00000000  [................]
        Repeat 504 times
01B0F53F0 00000000 00000000 00000000 FC661D01  [..............f.]
File Space Header Block:
Header Control:
RelFno: 54, Unit: 8, Size: 4194290, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0
Initial Area: 7, Tail: 4194280, First: 0, Free: 716
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2

--我们可以看到位图区位于4194281,4194282,4194283.

--如果我修改33554392 -8 =33554384k,这样结尾仅仅剩余2块,是无法容纳位图区,看看oracle是如何操作的?

SYS@xxxxx> ALTER DATABASE DATAFILE 54 RESIZE 33554384K;
Database altered.

SYS@xxxxx> alter system dump datafile 54  block  2;
System altered.

Start dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2
buffer tsn: 18 rdba: 0x0d800002 (54/2)
scn: 0x0002.db459295 seq: 0x01 flg: 0x00 tail: 0x92951d01
frmt: 0x02 chkval: 0x0000 type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000001B31C400 to 0x000000001B31E400
01B31C400 0000A21D 0D800002 DB459295 00010002  [..........E.....]
01B31C410 00000000 00000036 00000008 003FFFFA  [....6.........?.]
01B31C420 00000001 00000000 00000000 00000007  [................]
01B31C430 003FFFF0 00000000 000002CD 00000000  [..?.............]
01B31C440 00000000 00000000 00000000 A9010000  [................]
01B31C450 003FFFF1 00000003 00000000 00000000  [..?.............]
01B31C460 00000000 00000000 00000000 00000000  [................]
        Repeat 504 times
01B31E3F0 00000000 00000000 00000000 92951D01  [................]
File Space Header Block:
Header Control:
RelFno: 54, Unit: 8, Size: 4194298, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0
Initial Area: 7, Tail: 4194288, First: 0, Free: 717
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2

--可以发现位图区发生了改变,但是并没有移动到最后,tail:4194288。位图区4194289,4194290,4194291

SYS@xxxxx> ALTER DATABASE DATAFILE 54 RESIZE 33554392K;
Database altered.

SYS@xxxxx> alter system dump datafile 54  block  2;
System altered.

*** 2015-01-13 10:04:34.379
Start dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2
buffer tsn: 18 rdba: 0x0d800002 (54/2)
scn: 0x0002.db45dfc4 seq: 0x01 flg: 0x00 tail: 0xdfc41d01
frmt: 0x02 chkval: 0x0000 type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000001B31C400 to 0x000000001B31E400
01B31C400 0000A21D 0D800002 DB45DFC4 00010002  [..........E.....]
01B31C410 00000000 00000036 00000008 003FFFFB  [....6.........?.]
01B31C420 00000001 00000000 00000000 00000007  [................]
01B31C430 003FFFF8 00000000 000002CE 00000000  [..?.............]
01B31C440 00000000 00000000 00000000 A9010000  [................]
01B31C450 003FFFF9 00000003 00000000 00000000  [..?.............]
01B31C460 00000000 00000000 00000000 00000000  [................]
        Repeat 504 times
01B31E3F0 00000000 00000000 00000000 DFC41D01  [................]
File Space Header Block:
Header Control:
RelFno: 54, Unit: 8, Size: 4194299, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0
Initial Area: 7, Tail: 4194296, First: 0, Free: 718
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2

--仅仅数据文件增加8k,这样结尾正好能非放下3块。位图区4194297,4194298,4194299.从视图也可以确定。

SYS@xxxxx> select * from dba_data_files where file_id=54;
FILE_NAME                                                         FILE_ID TABLESPACE_NAME                       BYTES       BLOCKS STATUS    RELATIVE_FNO AUT     MAXBYTES    MAXBLOCKS INCREMENT_BY   USER_BYTES  USER_BLOCKS ONLINE_
------------------------------------------------------------ ------------ ------------------------------ ------------ ------------ --------- ------------ --- ------------ ------------ ------------ ------------ ------------ -------
+G0/xxxxx/datafile/xxxxx_check_lis.20490.852033985                     54 xxxxx_CHECK_LIS                 34359697408      4194299 AVAILABLE           54 NO             0            0            0  34359607296      4194288 ONLINE

--BLOCKS =4194299.

--也就是数据文件大小改变时结尾要保留放下位图区的空间,后面的空间就浪费了。

--减少8k时:
SYS@xxxxx> ALTER DATABASE DATAFILE 54 RESIZE 33554384K;
Database altered.

SYS@xxxxx> alter system dump datafile 54  block  2;
System altered.

*** 2015-01-13 10:12:31.841
Start dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2
buffer tsn: 18 rdba: 0x0d800002 (54/2)
scn: 0x0002.db46da1f seq: 0x01 flg: 0x00 tail: 0xda1f1d01
frmt: 0x02 chkval: 0x0000 type: 0x1d=KTFB Bitmapped File Space Header
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000001B31C400 to 0x000000001B31E400
01B31C400 0000A21D 0D800002 DB46DA1F 00010002  [..........F.....]
01B31C410 00000000 00000036 00000008 003FFFFA  [....6.........?.]
01B31C420 00000001 00000000 00000000 00000007  [................]
01B31C430 003FFFF0 00000000 000002CD 00000000  [..?.............]
01B31C440 00000000 00000000 00000000 00000000  [................]
01B31C450 003FFFF1 00000003 00000000 00000000  [..?.............]
01B31C460 00000000 00000000 00000000 00000000  [................]
        Repeat 504 times
01B31E3F0 00000000 00000000 00000000 DA1F1D01  [................]
File Space Header Block:
Header Control:
RelFno: 54, Unit: 8, Size: 4194298, Flag: 1
AutoExtend: NO, Increment: 0, MaxSize: 0
Initial Area: 7, Tail: 4194288, First: 0, Free: 717
Deallocation scn: 0.0
Header Opcode:
Save: No Pending Op
End dump data blocks tsn: 18 file#: 54 minblk 2 maxblk 2

SYS@xxxxx> select * from dba_data_files where file_id=54;
FILE_NAME                                                         FILE_ID TABLESPACE_NAME                       BYTES       BLOCKS STATUS    RELATIVE_FNO AUT     MAXBYTES    MAXBLOCKS INCREMENT_BY   USER_BYTES  USER_BLOCKS ONLINE_
------------------------------------------------------------ ------------ ------------------------------ ------------ ------------ --------- ------------ --- ------------ ------------ ------------ ------------ ------------ -------
+G0/xxxxx/datafile/xxxxx_check_lis.20490.852033985                     54 xxxxx_CHECK_LIS                 34359689216      4194298 AVAILABLE           54 NO             0            0            0  34359541760      4194280 ONLINE

--BLOCKS=4194298.位图区4194289,4194290,4194291, 后面的4194292-4194298就浪费了,当然这点空间根本不算什么。

----对于asm就不算什么,因为aus=1M。

目录
相关文章
|
4天前
|
云安全 人工智能 运维
阿里云联动百位企业安全专家,共识Agent防御最佳实践
当Agent成为新员工,你的安全边界在哪里?
1739 2
阿里云联动百位企业安全专家,共识Agent防御最佳实践
|
12天前
|
人工智能 JSON 安全
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
阿里云AI安全产品联动防御Fastjson攻击
2480 13
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
|
12天前
|
人工智能 自然语言处理 数据挖掘
Qwen3.8-Max-Preview深度全解析:2.4万亿参数旗舰MoE模型+Token Plan限时优惠完整落地指南
2026年7月,全新旗舰级混合专家大模型Qwen3.8-Max-Preview正式开放抢先体验,作为通义千问Qwen3系列规格最高、综合推理能力顶尖的新一代模型,该模型总参数量达到2.4万亿(2.4T),是当前线上可调用的原生多模态旗舰模型,综合推理水准对标海外顶级Fable 5模型,在复杂工程开发、长文档深度分析、多步骤智能体自治、跨境多语言创作、海量数据挖掘五大高难度业务场景实现跨越式性能提升。
1214 2
|
10天前
|
人工智能 前端开发 Linux
Codex 桌面版安装 + CC Switch 接入第三方 API 完整教程(2026 最新)
2026最新教程:手把手教你安装Codex桌面版,通过CC Switch v3.17.0一键接入Fenno等国产API(兼容OpenAI Responses格式),跳过账号登录,完整启用代码审查、多步任务与上下文感知功能。零基础友好,全程图文实操。(239字)
1039 2
|
14天前
|
人工智能
Qwen3.8抢先体验!正式版即将发布并开源!
千问Qwen3.8即将开源,参数达2.4T,进化速度以“天”计,实力媲美Fable 5。预览版Qwen3.8-Max已上线阿里Token Plan等平台,限时优惠:日间Credits低至1折,夜间更优,个人/团队版月付仅35元起!
1238 51
|
11天前
|
自然语言处理 测试技术 API
通义千问Qwen3.8-Max-Preview全功能解析:2.4万亿参数旗舰模型深度使用指南
在大模型技术持续迭代的当下,通义千问推出的Qwen3.8-Max-Preview作为新一代旗舰预览版模型,凭借2.4万亿参数的超大规模、多模态融合能力与全场景适配特性,成为开发者与企业用户探索AI应用的核心工具。该模型采用稀疏混合专家(MoE)架构,是通义千问首个突破万亿参数的多模态模型,可同时处理文本、图像、视频与文档等多种数据形态,在全栈代码开发、复杂逻辑推理、长文档分析与多智能体协作等场景实现跨越式升级。本文将全面拆解Qwen3.8-Max-Preview的核心功能,详解API调用流程与配置方法,覆盖多场景实战技巧,帮助用户快速掌握这款旗舰模型的使用方法,充分释放其性能潜力。
613 2
|
11天前
|
SQL 关系型数据库 MySQL
【2026最新】DBeaver下载、安装、数据库管理一篇搞定(附官网社区版安装包)
DBeaver是一款免费开源的跨平台通用数据库管理工具,支持MySQL、PostgreSQL、SQLite、Oracle等几乎所有主流数据库,无需为每种数据库安装独立客户端,极大提升开发与数据分析效率。