zoukankan      html  css  js  c++  java
  • 记一次oracle内存分配不足,前端访问500报错,如何扩容oracle的memory_target内存

         一次开发找到了我,说前端访问500,第一感觉就是访问后端的数据库挂了,且报错没有足够的内存,报错如下,实际看了下数据库是活着的,物理内存充足,应该是分配oracle的SGA内存不足了。

     由于经验不足,我的第一感觉,内存不足了,要扩容了,于是各种请教查询文档,在测试服务器上模拟出,如何扩容?流程如下:

    1.show parameter mem  查看系统分配给oracle的内存

    memory_target是oracle11g新出的内存自动管理工具,可以自动管理sga和pga的内存,不需要在像以前一样去手动设置了,

    11g特性的内存管理需要用到/dev/shm共享文件系统,且要求/dev/shm大于 TARGET_MEMORY,否则会报错。

    SQL> show parameter mem

    NAME                     TYPE     VALUE
    ------------------------------------ ----------- ------------------------------
    hi_shared_memory_address         integer     0
    inmemory_adg_enabled             boolean     TRUE
    inmemory_clause_default          string
    inmemory_expressions_usage         string     ENABLE
    inmemory_force                 string     DEFAULT
    inmemory_max_populate_servers         integer     0
    inmemory_query                 string     ENABLE
    inmemory_size                 big integer 0
    inmemory_trickle_repopulate_servers_ integer     1
    percent
    inmemory_virtual_columns         string     MANUAL

    NAME                     TYPE     VALUE
    ------------------------------------ ----------- ------------------------------
    memory_max_target             big integer 4G        ------>系统分配给oracle最大的内存,要>= sga内存的大小
    memory_target                     big integer 4G
    optimizer_inmemory_aware         boolean     TRUE
    shared_memory_address             integer     0
    2.现在就是要扩容这块的大小,一般分配为物理内存的50%~80%

    我们分配为6G.

    3.查看/dev/shm虚拟内存的大小,在扩容memory_max_target之前要先扩容此虚拟内存

    [oracle@scp ~]$ df -h
    Filesystem               Size  Used Avail Use% Mounted on
    /dev/mapper/centos-root   41G   27G   15G  64% /
    devtmpfs                 4.8G     0  4.8G   0% /dev
    tmpfs                     4.0G  1.1G  1.7G  42% /dev/shm

    [oracle@scp ~]$ vim /etc/fstab  在此文件的最后一行增加

    tmpfs                   /dev/shm            tmpfs   defaults,size=6144M        0 0

    mount -o remount,rw /dev/shm/   以可读写的方式重新加载/dev/shm磁盘

    再次查看,发现   /dev/shm已经扩容

    [root@scp ~]# df -h
    Filesystem               Size  Used Avail Use% Mounted on
    /dev/mapper/centos-root   41G   27G   15G  64% /
    devtmpfs                 4.8G     0  4.8G   0% /dev
    tmpfs                    6.0G  2.4G  3.7G  39% /dev/shm

    4.扩容memory_max_target

    su - oracle

    alter system set memory_max_target  =6G scope=spfile;

    alter system set memory_target      =6G scope=spfile;

    5.重启数据库

    shut immediate

    startup

    lsnrctl start  启动监听

    6.此时再次查看,已经扩容

    SQL> show parameter mem;

    NAME                     TYPE     VALUE
    ------------------------------------ ----------- ------------------------------
    hi_shared_memory_address         integer     0
    inmemory_adg_enabled             boolean     TRUE
    inmemory_clause_default          string
    inmemory_expressions_usage         string     ENABLE
    inmemory_force                 string     DEFAULT
    inmemory_max_populate_servers         integer     0
    inmemory_query                 string     ENABLE
    inmemory_size                 big integer 0
    inmemory_trickle_repopulate_servers_ integer     1
    percent
    inmemory_virtual_columns         string     MANUAL

    NAME                     TYPE     VALUE
    ------------------------------------ ----------- ------------------------------
    memory_max_target             big integer 6G
    memory_target                 big integer 6G

    但是,但是,我并没有在生产库上进行扩容,毕竟对oracle不熟,我还是请教了我们有经验的Oracle DBA,因为我们的这个数据库毕竟特殊,只有内部四五个人使用,按道理不会有太大并发,于是请那么dba帮忙排查

    大概思路就是,他先拉了一份,awr报告,发现cpu的等待时间比较久,每条语句的执行时间并不长,次数还是比较多,实际查看了tomcat的服务器的cpu竟然只有2核,所以怀疑是tomcat的服务器的CPU比较少需要高强度的运算所以,数据库的等待比较多,导致内存不足,所以建议扩容了cpu的核数,

    果然问题解决了,哎。不得不说经验很重要。。。。我还是太菜了。。。。。。

  • 相关阅读:
    组合数
    POJ2774 Long Long Message
    后缀排序【后缀数组入门题】
    luogu P3205 [HNOI2010]合唱队 区间dp
    luogu P3119 [USACO15JAN]Grass Cownoisseur G 有向图强连通分量+分层最短路
    luogu P3469 [POI2008]BLO-Blockade 割点
    luogu P2569 [SCOI2010]股票交易 单调优化dp
    luogu P2939 [USACO09FEB]Revamping Trails G 分层最短路
    luogu P3957 跳房子 二分+斜率优化dp
    luogu P1772 [ZJOI2006]物流运输 spfa最短路+dp
  • 原文地址:https://www.cnblogs.com/liuxiuxiu/p/13129932.html
Copyright © 2011-2022 走看看