请教各位, 我用的是Solaris系统下的Oracle 9i 数据库。在启动数据库的时候发现 sga 信息中的database buffers 的大小为 19G。然后我在查看系统内存使用情况的时候发现Oracle 占用了20G的内存。(1) . 我对Oracle的cache 不是很清楚,难道在数据启动时的database buffers 的大小占用的是内存的资源?如果是这样,database buffers的信息主要是包括数据库的哪些方面的内容?(2) . 如果 我盲目的扩大了 数据库的一个表空间的大小,并增加了数个表空间的数据文件,会不会引起 数据库启动时候的database buffers的大小增加?(3) . 如果需要减少数据库启动时 database buffers 的大小,(前提是不影响当前数据库中的数据)仅仅修改db_cache_size 就可以吗?会不会存在什么数据安全的隐患? 
请各位高人赐教。万分感谢!

解决方案 »

  1.   

    1.The oracle documentataion can explain it:
    The System Global Area (SGA) is a shared memory region that contains data and control information for one Oracle instance. Oracle allocates the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA.Users currently connected to an Oracle database share the data in the SGA. For optimal performance, the entire SGA should be as large as possible (while still fitting in real memory) to store as much data in memory as possible and to minimize disk I/O.The information stored in the SGA is divided into several types of memory structures, including the database buffers, redo log buffer, and the shared pool.2.不会,数据文件用的是硬盘空间,不是宝贵的内存空间。3。不怎么清楚。
      

  2.   


    1. 1楼解释的相当的清楚2. oracle的数据文件是数据存储的空间,而db buffer是内存空间,这两个是分开的概念。不会相互影响,数据量增大倒是会增加db buffer size的使用,不过你的数据库看是9i,所以实例的database buffer的大小只是受db_cache_size限制。3. 理论上 db_cache_size不会影响到数据库里的数据的,毕竟这是个内存的控制参数而已,如果是9i,要改变database buffers大小,调整db_cache_size即可,不过可能对数据库的性能有所影响。调整前,最好通过create pfile='pfile备份地址' from spfile;先备份你的spfile;==================================================================
    Inthirties关注Oracle数据库 维护 优化,安全,备份,恢复,迁移,故障处理如果你需要帮助或想和我一起学习的请联系
    联系方式QQ:370140387
    电子邮件:[email protected]
    网站: http://www.inthirties.com
      

  3.   

    难道在数据启动时的database buffers 的大小占用的是内存的资源?
    ================================================================
    当然,任何数据,要对其进行操作都要先读到内存中来,因为磁盘是块设备,是不能按字节寻址的。
    会不会引起 数据库启动时候的database buffers的大小增加?
    =============================================================
    数据库的大小和 db_buffer 的大小没有必然的联系
    会不会存在什么数据安全的隐患? 
    ==================================================
    可以,但最好不要随意调整。
      

  4.   

    谢谢各位。问题我基本上清楚了,不知这样理解对不对,可能是由于数据量的急剧增加(表现在我需要增加表空间的数据文件来增加表空间)导致database buffers 的大小相应增加了许多。因为这个大小占用的是内存的资源,因此导致了我的服务器系统内存不够。
    如果上述理解正确的话,那么我需要怎么来解决这个问题?
    1. 我删除数据库的一个用户(users) 包括该用户下面的数据(drop user username cascade;)
    这样 在关闭数据库之后重新打开,database buffers的大小会不会 减少?2. 调整 db_cache_size 的大小不会对数据库的数据有影响,但是会使数据库的性能下降。那么我需要怎样备份现有的这个配置环境,以便在我觉得修改之后导致我的数据库的性能下降得太厉害,而需要恢复的时候可以改回来?
    to Inthirties: “ 最好通过create pfile='pfile备份地址' from spfile;先备份你的spfile;” 不好意思,能不能把一个完整的语句告诉我,如何创建备份的pfile文件,又如何恢复?谢谢!
      

  5.   


    备份
    create pfile='c:/bak/pfilebak.ora' from spfile;
    恢复:
    startup pfile='c:/bak/pfilebak.ora' ;
      

  6.   

    1. 我删除数据库的一个用户(users) 包括该用户下面的数据(drop user username cascade;) 
    这样 在关闭数据库之后重新打开,database buffers的大小会不会 减少? 
      

  7.   

    create pfile='c:/bak/pfilebak.ora' from spfile; 
    提示找不文件怎么办?
    怎样区别数据库启动时pfile还是spfile,如果是pfile启动又该如何备份呢?谢谢!
      

  8.   


    检查一下你的目录c:/bak/是不是存在的,关于启动参数文件的加载,oracle有自己的一套优先规则,你可以google查一下从指定的pfile启动的命令如下
    startup pfile='你的pfile的路径';和普通的startup的命令一样,你可以指定启动的状态,nomount, mount, open, 不指定的话,是open。
      

  9.   

    路径确定存在了,可是出现这个错误。该怎么做?谢谢!SQL> create pfile = 'export/d1/data_proc/pfilebak.ora' from spfile;
    create pfile = 'export/d1/data_proc/pfilebak.ora' from spfile
    *
    ERROR at line 1:
    ORA-07391: sftopn: fopen error, unable to open text file.
      

  10.   

    spfile路径如下
    SQL> show parameter spfileNAME      TYPE  VALUE
    ------------------------------------ ----------- ------------------------------
    spfile      string  ?/dbs/[email protected]
      

  11.   

    这样做就可以 很奇怪,难道就是权限不够吗?
    create pfile='/tmp/pfilebak.ora' from spfile;
      

  12.   


    根据提示信息,估计还是是你的pfile的路径没有指定对,你确定export/d1/data_proc/存在。这里你没有指定绝对路径,应该是在ORACLE_HOME/dbs/下找这个这个路径,应该你是没有这个路径的。在确认一下。这里Oracle给的信息很明确了。unable to open text file.
      

  13.   

    thank. 问题已经解决了。谢谢各位。我在itpub上发了几天的贴都没人理。还是这里好!
    谢谢各位。