Oracle Study之案例--通过IPCS查看共享内存之“怪现象”

Oracle Study之案例--通过IPCS查看共享内存之“怪现象”   

在Oracle 11gR2环境下,通过ipcs命令查看共享内存,竟然发现分配给Oracle的内存只有4096Bytes,而在Oracle 10g环境下从未发现这种问题!

[[email protected] ~]# ipcs -a
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 0          root       644        52         2
0x00000000 32769      root       644        16384      2
0x00000000 65538      root       644        268        2
0x00000000 98307      gdm        600        393216     2          dest
0x00000000 131076     gdm        600        393216     2          dest
0x00000000 163845     gdm        600        393216     2          dest
0x00000000 196614     gdm        600        393216     2          dest
0x00000000 229383     gdm        600        393216     2          dest
0x4b4218ec 557064     oracle     660        4096       0
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x00000000 0          root       600        1
0x00000000 98305      root       600        1
0x000000a7 327682     root       600        1
0xbe61d9cc 983043     oracle     660        154
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

数据库版本:

16:27:09 [email protected] test3 >select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production

Oraccle 11g的通过以下两个参数实现内存的自动个管理:

16:27:19 [email protected] test3 >show parameter mem
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address             integer     0
memory_max_target                    big integer 300M
memory_target                        big integer 300M
shared_memory_address                integer     0

1、会不会是参数memory_max_target有关系呢?把它设为0,然后重启数据库。

16:28:11 [email protected] test3 >alter system set memory_target=0 ;
System altered.

16:36:44 [email protected] test3 >show parameter mem

NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
hi_shared_memory_address             integer                0
memory_max_target                    big integer            300M
memory_target                        big integer            0
shared_memory_address                integer                0

16:30:51 [email protected] test3 >startup force ;
ORACLE instance started.
Total System Global Area  313860096 bytes
Fixed Size                  1336232 bytes
Variable Size             205524056 bytes
Database Buffers          100663296 bytes
Redo Buffers                6336512 bytes
Database mounted.
Database opened.

再看共享内存:

[[email protected] ~]$ ipcs -a
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 0          root       644        52         2
0x00000000 32769      root       644        16384      2
0x00000000 65538      root       644        268        2
0x4b4218ec 622600     oracle     660        4096       0
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0xbe61d9cc 1114115    oracle     660        154
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

发现分配给Oracle的共享内存仍然很小,看来不是memory_target 参数的问题!

2、尝试调整memory_max_target参数,将其恢复到系统默认值:

16:39:49 [email protected] test3 >alter system set sga_max_size=300m scope=spfile;
System altered.

16:40:06 [email protected] test3 >alter system reset memory_max_target scope=spfile sid=‘*‘;
System altered.

16:40:40 [email protected] test3 >startup force nomount;
ORACLE instance started.
Total System Global Area  313860096 bytes
Fixed Size                  1336232 bytes
Variable Size             205524056 bytes
Database Buffers          100663296 bytes
Redo Buffers                6336512 bytes

16:40:52 [email protected] test3 >show parameter mem
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
hi_shared_memory_address             integer                0
memory_max_target                    big integer            0
memory_target                        big integer            0
shared_memory_address                integer                0

16:40:59 [email protected] test3 >show parameter sga
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
lock_sga                             boolean                FALSE
pre_page_sga                         boolean                FALSE
sga_max_size                         big integer            300M
sga_target                           big integer            180M

查看系统共享内存:

[[email protected] ~]$ ipcs -a
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 0          root       644        52         2
0x00000000 32769      root       644        16384      2
0x00000000 65538      root       644        268        2
0x4b4218ec 884744     oracle     660        316669952  16
------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0xbe61d9cc 1638403    oracle     660        154
------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

看来是设置了memory_max_target参数的原因,导致通过ipcs查看到分配给Oracle的内存为4096Bytes!

时间: 2024-08-01 00:40:06

Oracle Study之案例--通过IPCS查看共享内存之“怪现象”的相关文章

Oracle Study之--IPCS管理共享内存

Oracle Study之--IPCS管理共享内存 Unix/linux下的共享内存.信号量.队列信息管理 在unix/linux下,经常有因为共享内存.信号量,队列等共享信息没有干净地清除而引起一些问题. 查看共享信息的内存的命令是:ipcs [-m|-s|-q]. 默认会列出共享内存.信号量,队列信息 -m列出共享内存 -s列出共享信号量 -q列出共享队列 清除命令是:ipcrm [-m|-s|-q] id. -m 删除共享内存 -s删除共享信号量 -q删除共享队列. 案例分析: [[ema

Oracle Study之案例--安装Oracle内核参数配置

Oracle Study之案例--安装Oracle内核参数配置 在Linux系统下,安装Oracle之前,除了检查操作系统的硬件和软件是否满足安装需要之外,一个重点就是修改内核参数,其中最主要的是和内存相关的参数设置. 案例分析: 查看当前系统的内核参数配置: [[email protected] ~]# sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.acce

Oracle Study之案例--异构平台传输表空间(Linux至AIX)

Oracle Study之案例--异构平台传输表空间(Linux至AIX) 系统架构: 可                   源    库               目标库 操作系统 Linux RH6    AIX 5.3-09 主机名 rh6(192.168.8.245) aix211(192.168.8.211) 数据版本 Oracle 11gR2 Oracle 11gR2 数据库名 prod orcl 表空间 test1 test1    可传输表空间概述 Oracle 的可传输表空

Oracle Study之案例--数据恢复神器Flashback(1)

Oracle Study之案例--数据恢复神器Flashback(1) Flashback: Flashback 技术是以Undo segment中的内容为基础的, 因此受限于UNDO_RETENTON参数.要使用flashback 的特性,必须启用自动撤销管理表空间. 在Oracle 11g里又出了一个新特性:Oracle Flashback Data Archive. FDA通过将变化数据另外存储到创建的闪回归档区(Flashback Archive)中,以和undo区别开来,这样就可以为闪

Oracle Study之案例--Oracle ASSM管理方式下的BITMAP

Oracle Study之案例--Oracle ASSM管理方式下的Bitmap      在基于此在LMT(Extent Local Management)下Oracle建议我们使用ASSM(Automatic Segment-Space Management),看看 Oracle doc是如何来解释ASSM的: This keyword tells Oracle that you want to use bitmaps to manage the free space with in seg

Oracle Study之案例--重建数据库控制文件

Oracle Study之案例--重建数据库控制文件 系统环境: 操作系统: Linux RH6 数据库:   Oracle 11gR2    案例分析:           数据库中所有的控制文件被意外破坏,非归档的库,在有trace备份的情况下,重建控制文件. 1.控制文件trace脚本 [[email protected] ~]$ cat crctr.sql  CREATE CONTROLFILE REUSE DATABASE "TEST3" NORESETLOGS  NOARC

Oracle Study之案例--Oracle 11g DataGuard Snapshot Standby

Oracle Study之案例--Oracle 11g  DataGuard Snapshot Standby Oracle 11g的Data Guard不仅仅带给我们的是Active Data Guard实时查询特性,同时还带来了另外一个新特性,这便是Snapshot Standby数据库功能,此项功能可将备库置身于"可读写状态"用于不方便在生产环境主库中测试的内容,比如模拟上线测试等任务.当备库读写状态下任务完成后,可以非常轻松的完成Snapshot Standby数据库角色切换回

Oracle Study之案例--在RAW上controlfile多元化

Oracle Study之案例--在RAW上controlfile多元化 系统环境: 操作系统: AIX 5300-08 数据库:   Oracle 10.2.0.1 在通过dbca建库后,有两个控制文件,再添加一个控制文件 1.查看controlfile信息 [[email protected]:/home/oracle]$sqlplus '/as sysdba' SQL*Plus: Release 10.2.0.1.0 - Production on Wed Nov 19 11:15:45 

Oracle Study之案例--RMAN ORA-19921错误

Oracle Study之案例--RMAN ORA-19921错误 系统环境: 操作系统: AIX5.3 Oracle:   Oracle 10gR2 错误现象:         数据库在通过rman连接时出现以下错误: [11:01:51 [email protected]: ~]$rman target / Recovery Manager: Release 10.2.0.1.0 - Production on Mon Jan 19 11:01:53 2015 Copyright (c) 1