经验闲谈

EBS Oracle库问题之变更oracle process数

留下评论

早上遇到一套环境数据库突然不能连接，应用也无法连接，查询alert_PROD.log发现连接数超过最高200，于是最快的方式是增加process连接数。先关闭应用，此时去关闭的时候已经提示不能连上数据库，于是通过ps -fu applprod，把相应的进程都kill掉。然后连上数据库的服务器，sqlplus方式连接去关闭数据库。其实这个时候关闭后会将大部分的进程释放掉，这个时候去启动应用应该可以正常启动，但是考虑到200的process数太小，还是决定增大。于是按照下面方式进行：

遇到在增加ebs Oracle process数据的时候错误，解决方式：

1、show parameter spfile;

2、create parameter pfile;

3、shutdown immediate;

4、startup;

5、alter system set processes=800 scope=spfile;

6、shutdown immediate;

7、重启数据库、重启应用。

参考：

调整数据库SGA区的大小

默认安装完毕后，数据库的SGA的大小是1G。根据电脑内存大小和下面的表格作适当的调整。

数据库初始化参数建议值

Parameter Name Development or Test Instance 11-100 Users 101-500 Users 501-1000 Users 1001-2000 Users
processes 200 200 800 1200 2500
sessions 400 400 1600 2400 5000
sga_target 1G 1G 2G 3G 14G
shared_pool_size (csp) N/A N/A N/A 1800M 3000M
shared_pool_reserved_size(csp) N/A N/A N/A 180M 300M
shared_pool_size (no csp) 400M 600M 800M 1000M 2000M
shared_pool_reserved_size(no csp) 40M 60M 80M 100M 100M
pga_aggregate_target 1G 2G 4G 10G 20G
Total Memory Required ~ 2 GB ~ 3 GB ~ 6 GB ~ 13 GB ~ 34 GB

以数据库用户oraprod登录，修改Oracle数据库的初始化文件

/u01/oracle/PROD/db/tech_st/11.1.0/dbs/initPROD.ora

备份文件initPROD.ora

cd /u01/oracle/PROD/db/tech_st/11.1.0/dbs/

cp initPROD.ora initPROD.ora.bak_<替换为修改日期>

vi initPROD.ora

修改如下内容

processes          = 800     ###默认值200

sessions           = 1600    ###默认值400

sga_target         = 2G      ###默认值1G

shared_pool_size   = 800M    ###默认值400M

shared_pool_reserved_size = 80M ###默认值40M

pga_aggregate_target     = 4G   ###默认值 1G

因为我的内存有64G，所以把这两个参数扩大了点。根据实际情况，如果你只有1G内存的话，建议你把这两个参数都调整成512M或更小。

1、关应用；
2、关数据库；
3、数据库用户：
cd $ORACLE_HOME/dbs
cp initPROD.ora initPROD.ora.bak20190703
vi initPROD.ora
找到具体指标：
processes = 800 ###默认值200
sessions = 1600 ###默认值400
sga_target = 2G ###默认值1G
shared_pool_size = 800M ###默认值400M
shared_pool_reserved_size = 80M ###默认值40M
pga_aggregate_target = 4G ###默认值 1G

保存后。
4、启动数据库；
5、启动应用。

转载文章（档）

TOP命令及Free语义分析（转载）

留下评论

接触 linux 的人对于 top 命令可能不会陌生（不同系统名字可能不一样，如 IBM 的 aix 中叫 topas ），它的作用主要用来监控系统实时负载率、进程的资源占用率及其它各项系统状态属性是否正常。

下面我们先来看张 top 截图：

（1）系统、任务统计信息：

前 8 行是系统整体的统计信息。第 1 行是任务队列信息，同 uptime 命令的执行结果。其内容如下：

01:06:48 当前时间
up 1:22 系统运行时间，格式为时:分
1 user 当前登录用户数
load average: 0.06, 0.60, 0.48 系统负载，即任务队列的平均长度。三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。

注意：这三个值可以用来判定系统是否负载过高——如果值

持续大于系统 cpu 个数，就需要优化你的程序或者架构了。

（2）进程、 cpu 统计信息：

第 2~6 行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：

Tasks: 29 total 进程总数
1 running 正在运行的进程数
28 sleeping 睡眠的进程数
0 stopped 停止的进程数
0 zombie 僵尸进程数
Cpu(s): 0.3% us 用户空间占用CPU百分比
1.0% sy 内核空间占用CPU百分比
0.0% ni 用户进程空间内改变过优先级的进程占用CPU百分比
98.7% id 空闲CPU百分比
0.0% wa 等待输入输出的CPU时间百分比
0.0% hi Hardware IRQ
0.0% si Software IRQ

注：

（1）IRQ: IRQ全称为Interrupt Request，即是“中断请求”的意思。

（2）st(Steal Time)：stole time 的缩写，该项指标只对虚拟机有效，表示分配给当前虚拟机的 CPU 时间之中，被同一台物理机上的其他虚拟机偷走的时间百分比

So, relatively speaking, what does this mean? A high steal percentage may mean that you may be outgrowing your virtual machine with your hosting company. Other virtual machines may have a larger slice of the CPU’s time and you may need to ask for an upgrade in order to compete. Also, a high steal percentage may mean that your hosting company is overselling virtual machines on your particular server. If you upgrade your virtual machine and your steal percentage doesn’t drop, you may want to seek another provider. A low steal percentage can mean that your applications are working well with your current virtual machine. Since your VM is not wrestling with other VM’s constantly for CPU time, your VM will be more responsive. This may also suggest that your hosting provider is underselling their servers, which is definitely a good thing.0.0% sisi(Software Interrupts)

（3）最后两行为内存信息：

Mem: 191272k total 物理内存总量
173656k used 使用的物理内存总量
17616k free 空闲内存总量
22052k buffers 用作内核缓存的内存量
Swap: 192772k total 交换区总量
0k used 使用的交换区总量
192772k free 空闲交换区总量
123988k cached 缓冲的交换区总量。
内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，
该数值即为这些内容已存在于内存中的交换区的大小。
相应的内存再次被换出时可不必再对交换区写入。

PS：如何计算可用内存和已用内存？

除了 free -m 之外，也可以看 top：

Mem:    255592k total,   167568k used,    88024k free,    25068k buffers
Swap:   524280k total,        0k used,   524280k free,    85724k cached

3.1  实际的程序可用内存数怎么算呢？

The answer is: free + (buffers + cached)

88024k + (25068k + 85724k) = 198816k

3.2  程序已用内存数又怎么算呢？

The answer is: used – (buffers + cached)

167568k – (25068k + 85724k) = 56776k

3.3  怎么判断系统是否内存不足呢？

如果你的 swap used 数值大于 0 ，基本可以判断已经遇到内存瓶颈了，要么优化你的代码，要么加内存。

3.4  buffer 与cache 的区别

A buffer is something that has yet to be “written” to disk. A cache is something that has been “read” from the disk and stored for later use 从应用程序角度来看，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读写的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。
所以从应用程序的角度来说，可用内存 = 系统free memory + buffers + cached.

buffers是指用来给块设备做的缓冲大小，他只记录文件系统的metadata以及 tracking in-flight pages.
cached是用来给文件做缓冲。
那就是说：buffers是用来存储，目录里面有什么内容，权限等等。
而cached直接用来记忆我们打开的文件，如果你想知道他是不是真的生效，你可以试一下，先后执行两次命令#man X ,你就可以明显的感觉到第二次的开打的速度快很多。

实验：在一台没有什么应用的机器上做会看得比较明显。记得实验只能做一次，如果想多做请换一个文件名。

#free
#man X
#free
#man X
#free
你可以先后比较一下free后显示buffers的大小。
另一个实验：
#free
#ls /dev
#free
你比较一下两个的大小，当然这个buffers随时都在增加，但你有ls过的话，增加的速度会变得快，这个就是buffers/chached的区别。
因为Linux将你暂时不使用的内存作为文件和数据缓存，以提高系统性能，当你需要这些内存时，系统会自动释放（不像windows那样，即使你有很多空闲内存,他也要访问一下磁盘中的pagefiles）

（4）进程信息区：

统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。

序号 列名 含义
a PID 进程id
b PPID 父进程id
c RUSER Real user name
d UID 进程所有者的用户id
e USER 进程所有者的用户名
f GROUP 进程所有者的组名
g TTY 启动进程的终端名。不是从终端启动的进程则显示为 ?
h PR 优先级
i NI nice值。负值表示高优先级，正值表示低优先级
j P 最后使用的CPU，仅在多CPU环境下有意义
k %CPU 上次更新到现在的CPU时间占用百分比
l TIME 进程使用的CPU时间总计，单位秒
m TIME+ 进程使用的CPU时间总计，单位1/100秒
n %MEM 进程使用的物理内存百分比
o VIRT 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
p SWAP 进程使用的虚拟内存中，被换出的大小，单位kb。
q RES 进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
r CODE 可执行代码占用的物理内存大小，单位kb
s DATA 可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
t SHR 共享内存大小，单位kb
u nFLT 页面错误次数
v nDRT 最后一次写入到现在，被修改过的页面数。
w S 进程状态。
D=不可中断的睡眠状态
R=运行
S=睡眠
T=跟踪/停止
Z=僵尸进程
x COMMAND 命令名/命令行
y WCHAN 若该进程在睡眠，则显示睡眠中的系统函数名
z Flags 任务标志，参考 sched.h

（5）查看指定列

默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。
可以通过下面的快捷键来更改显示内容：

5.1 f 键选择显示内容

通过 f 键可以选择显示的内容。按 f 键之后会显示列的列表，按 a-z 即可显示或隐藏对应的列，最后按回车键确定。

5.2 o 键改变显示顺序

按 o 键可以改变列的显示顺序。按小写的 a-z 可以将相应的列向右移动，而大写的 A-Z 可以将相应的列向左移动。最后按回车键确定。

5.3 F/O 键将进程按列排序

按大写的 F 或 O 键，然后按 a-z 可以将进程按照相应的列进行排序。而大写的 R 键可以将当前的排序倒转。

（6）常用交互命令

从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。
Ctrl+L 擦除并且重写屏幕。
h或者? 显示帮助画面，给出一些简短的命令总结说明。
k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序。
r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
S 切换到累计模式。
s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
f或者F 从当前显示中添加或者删除项目。
o或者O 改变显示项目的顺序。
l 切换显示平均负载和启动时间信息。
m 切换显示内存信息。
t 切换显示进程和CPU状态信息。
c 切换显示命令名称和完整命令行。
M 根据驻留内存大小进行排序。
P 根据CPU使用百分比大小进行排序。
T 根据时间/累计时间进行排序。
W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。

（7）最后的技能：top 命令小技巧

1、输入大写P，则结果按CPU占用降序排序。
2、输入大写M，结果按内存占用降序排序。
3、按数字 1 则可以显示所有CPU核心的负载情况。
4、top -d 5    每隔 5 秒刷新一次，默认 1 秒
5、top -p 4360,4358    监控指定进程
6、top -U johndoe    ‘U’为 真实/有效/保存/文件系统用户名。
7、top -u 500    ‘u’为有效用户标识
8、top -bn 1    显示所有进程信息，top -n 1 只显示一屏信息，供管道调用
9、top -M   #show memory summary in megabytes not kilobytes
10、top -p 25097 -n 1 -b    # -b 避免输出控制字符，管道调用出现乱码
11、top翻页：top -bn1 | less
12、增强版的 top：htop ，一个更加强大的交互式进程管理器：

File:Htop.png

附：进程相关基础知识

内存

内存基础

通常包含物理内存和虚拟内存（virtual Memory ），好处是通过物理内存（RAM) 和部分硬盘空间（SWAP ）组合增大了总体的内存空间，坏处是由于硬盘部分的虚拟内存的性能有限，并且RAM 和SWAP之间交换增加了系统的负担。 

1.  [phoenix.lif@aliadmin036158 ~]$ free

2.               total       used       free     shared    buffers     cached

3.  Mem:        7680000      7504764       175236            0       490772      3193856

4.  -/+ buffers/cache:     3820136      3859864

5.  Swap:       2096472           88      2096384

其中，Mem ：  

(1) Total 为总的物理内存；

(2) Used 表示总计分配给缓存使用的数量（即buffers 和cache ，但可能部分还未实际使用）；

(3)Free 表示未被分配的内存；

(4)share 表示共享内存，一般不会使用；

(5)buffers ：表示系统分配但未被使用的buffers 数量；

(6)Cached ：表示系统分配但未被使用的cache 数量。后面详细说明buffer 和cache 的区别。

-/+ buffers/cache:

(1)Used 表示实际使用的buffers 和cache 总量，即实际使用内存总量;

(2)Free 未被使用的buffer ，cache 及未被分配的内存之和，即系统可用内存。

Swap:  虚拟内存。如果系统物理内存用完了，但是仍有虚拟内存系统仍然可以运行虽然运行很慢；但是如果Swap 也用完了，系统就会发生错误，通常会出现”application is out of memory” 的错误，严重时造成系统死锁。通常Swap 空间分配为物理内存的2-2.5 倍，但也不用完全按照这个标准，如确定内存完全够用也没必要分配太多，我们线上的服务器就没有分配太多的Swap 空间。

tips:

实际可用内存：Free(-/+ buffers/cache) = Free(Mem)+buffers(Mem)+Cached(Mem);

已分配内存：Used(Mem) = Used(-/+ buffers/cache)+ buffers(Mem) + Cached(Mem)

物理内存总大小：total （Mem ） = used(-/+ buffers/cache) + free(-/+ buffers/cache)

Buffers & Cache

在 Linux 的实现中，文件 Cache 分为两个层面，一是 Page Cache ，另一个 Buffer Cache ，每一个Page Cache 包含若干 Buffer Cache 。内存管理系统和 VFS 只与 Page Cache 交互，内存管理系统负责维护每项 Page Cache 的分配和回收。buffer cache 是块设备的读写缓冲区，更靠近存储设备，或者直接就是disk 的缓冲区。

磁盘操作有逻辑级（文件系统）和物理级（磁盘块），这两种缓存分别是缓存逻辑和物理级数据的。如我们进行的是文件系统操作，那么文件被缓存到Page Cache ，如需要刷新文件的时候，Page Cache 将交给Buffer Cache 去完成，因为Buffer Cache 是缓存磁盘块的。即直接去操作文件就是使用Page Cache ，用dd 等命令直接操作磁盘块，就是buffer cache 缓存。

（8）Refer：

http://www.linuxidc.com/Linux/2011-03/33582.htm

http://os.51cto.com/art/201012/240719.htm

http://www.kernelhardware.org/linux-top-command/

http://unix.stackexchange.com/questions/18918/in-linux-top-command-what-are-us-sy-ni-id-wa-hi-si-and-st-for-cpu-usage

http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html

http://www.taobaotest.com/blogs/qa?bid=2265    linux命令free详解

http://blogread.cn/it/article/6386?f=wb    top使用技巧

http://yikebocai.com/2014/11/cpu-load-too-high/    CPU Load过高问题分析和解决方案

https://github.com/oldratlee/useful-scripts    useful-scripts：打印 java 占用资源高的线程

http://newslxw.iteye.com/blog/1495565    一篇很好的linux下内存，IO解析文章

http://alanwu.blog.51cto.com/3652632/1122077    Buffer cache和page cache的区别

http://www.penglixun.com/tech/system/the_diffrents_of_page_cache_and_buffer_cache.html    Page Cache和Buffer Cache的区别

http://csrd.aliapp.com/?p=13    The Page Cache FAQ(v0.1,欢迎补充与拍砖)

http://www.techug.com/4-process-manage-tools    Linux 进程管理之四大名捕

转自：http://blog.chinaunix.net/uid-25776631-id-5784283.html

系统层级、经验闲谈

AUM 常用分析/诊断脚本 (文档 ID 1526122.1)

留下评论

AUM 常用分析/诊断脚本 (文档 ID 1526122.1)

Oracle Database – Enterprise Edition – 版本 10.1.0.5 到 11.1.0.6 [发行版 10.1 到 11.1]

本文档所含信息适用于所有平台

用途

本文旨在规范对用以诊断和分析 ORA-1555 错误的脚本的使用。本文适用于所有数据库管理员及 Oracle Support 分析人员。

要求

以下脚本可在 SQL*Plus 或 iSQL*Plus 中运行。很多脚本都要求拥有数据库的 DBA 权限。

单击 此处 [修订时间：2011 年 5 月 12 日] 下载本文中讨论的脚本。

配置

查看每个脚本的备注以判定对于特定配置/应用程序环境是否提示有所更改。

说明

对于以下脚本，需要使用能够访问 DBA* 和 V$ 表的数据库管理用户。默认情况下，这些脚本登录形式为：

$ sqlplus /nolog

connect / as sysdba

这些脚本应该不会影响数据库性能，可以多次运行。

警告

此示例代码只为教育目的，Oracle Support不提供技术支持。它已经过内部测试，然而我们无法确保它在任何环境中都能成功使用。请您在使用之前先在测试环境中运行。

示例代码

Oracle 发布的用于调查 ORA-1555 错误的脚本每一版本都有所不同。这些脚本只适用于自动 UNDO 管理 (AUM) 配置的环境。

脚本文件以本文档附件的形式提供。注意：在本文档中执行剪切粘贴操作时，这些脚本可能出现格式问题。因此，脚本都附在文档中，可下载使用。本文将讨论每个脚本的优势/作用，并提供示例输出。

AUM 配置和 ORA-1555 全面分析

  1. 配置：

UndoDatafiles.sql — spool 输出到位于默认目录位置的文件 undodatafiles.out 中。

UndoParameters.sql — spool 输出到位于默认目录位置的文件 undoparameters.out 中。

UndoUsage.sql — spool 输出到位于默认目录位置的文件 undousage.out 中。

  1. 当前未提交的事务：

CurrentActivity.sql — spool 输出到位于默认目录位置的文件 undoactivity.out 中。

  1. 历史 UNDO 信息：

UndoHistoryInfo.sql — spool 输出到位于默认目录位置的 undohistory.out 中。

UndoStatistics.sql — spool 输出到位于默认目录位置的 undostatistics.out 中。您可修改此报告以显示适当的分析时间范围。默认情况下，查看最后两天的 V$UNDOSTAT 数据。在 V$UNDOSTAT 视图中，数据会保留七天。

  1. 等待/锁定分析：

UndoPressure.sql — spool 输出到位于默认目录位置的 undopressure.out 中。

  1. 调查 LOB 问题：

LobData.sql — spool 输出到位于默认目录位置的 lobdata.out 中。

示例输出

  1. 配置

示例 undodatafiles.out

############## RUNTIME ##############

Run Time

—————–

05-Aug-2009 08:53

############## DATAFILES ##############

Aut

TBSP Name                   File #   Bytes Alloc (MB) Max Bytes Used (MB) (MB)     Ext

—————————— —— ————————- ———————————— ——

SMALLUNDO                  3                              200                                     200     YES

查看配置数据。AUTOEXTEND 是否打开？如果 UNDO 表空间配置为随着空间需求自动增长，这会对数据库造成影响，数据库可能不会重新使用超过Retention设置的过期 Undo extent，以减少发生 ORA-1555 的几率。表空间进而会随着新的需求增长。

示例 undoparameters.out

############## RUNTIME ##############Run Time

—————–

05-Aug-2009 08:56

############## PARAMETERS ##############

Instance #  Parameter                              Session Value          Instance Value

————– ———————————– ————————- ————————-

1                 _smu_debug_mode                              33554432                  33554432

1                _undo_autotune                                         TRUE                        TRUE

1                undo_management                                    AUTO                       AUTO

1                undo_retention                                                900                             900

1                undo_tablespace                        SMALLUNDO          SMALLUNDO

查看影响 Undo Retention规则的参数设置。

‘_smu_debug_mode’=33554432 会强制让自动优化程序基于系统中运行时间最长的 SQL 的执行时间来计算自动的 undo retention。在默认情况下，自动调整后的保留时间会增长到很长的时间段，空间压力将成为 Undo 表空间中的重大问题。

‘_undo_autotune’=false 是一些 AUM bug 的权宜方法，但这会对分析产生重大影响。V$UNDOSTAT 中不会再进一步跟踪其他数据，显式指定的的 UNDO_RETENTION 设置是影响 undo Retention处理的关键。

示例 undousage.out

############## RUNTIME ##############

Run Time

————————–

05-Aug-2009 08:58

############## IN USE Undo Data ##############

PCT_INUSE

—————-

23.625

TABLESPACE_NAME    EXTENT_MAN    ALLOCATIO      SEGMEN      RETENTION

——————————— ———————— ———————- —————- —————–

SMALLUNDO                  LOCAL                    SYSTEM             MANUAL    NOGUARANTEE

Sum of Free

—————-

65,536

Total Bytes

—————-

209,715,200

############## UNDO SEGMENTS ##############

Status              Total Extents

—————— —————–

UNEXPIRED                    21

EXPIRED                        807

ACTIVE                          195

————-

sum                               1,023

 

Status               Total Segments

——————– ——————-

ONLINE                                  11

————-

sum                                          11

  1. 当前未提交的事务

示例 undoactivity.out

############## RUNTIME ##############

Run Time

—————–

19-Aug-2009 09:43

############## Current Uncommitted Transactions ##############

Started    User     Undo Segment Name            File #       Block #       Status         KBytes     Rows

———— ——— ————————————- ———— ————– ————– ————- ———-

08/19/09 KEN      _SYSSMU8_1245875459$                  3            9735     ACTIVE       48,664   614,178

09:43:02

查看未提交的事务。该事务有多大？什么用户在处理该事务？随着时间的推移，其是否显示为未提交？这在预期之内吗？在此事务之前开始的任何长时间运行的查询、或在此事务之前使用闪回功能都必须创建此数据的旧“副本”。

  1. 历史 UNDO 信息

示例 – undohistory.out

############## RUNTIME ##############

Run Time

—————–

05-Aug-2009 09:08

############## HISTORICAL DATA ##############

Max Concurrent

Last 7 Days

——————–

5

Max Concurrent

Since Startup

———————–

5

1555 Errors

—————

0

Undo Space Errors

————————-

0

############## CURRENT STATUS OF SEGMENTS ##############

############## SNAPSHOT IN TIME INFO ##############

##############(SHOWS CURRENT UNDO ACTIVITY)##############

Segment Name                      Active Bytes     Unexpired Bytes Expired Bytes

———————————– ——————— ———————- ——————–

_SYSSMU10_1245875459$                           0             1,114,112                 65,536

_SYSSMU1_1245875459$                             0             3,211,264          75,497,472

_SYSSMU2_1245875459$                             0                196,608                 65,536

_SYSSMU3_1245875459$                             0             1,507,328          55,115,776

_SYSSMU4_1245875459$             43,253,760                           0                          0

_SYSSMU5_1245875459$                             0             1,048,576          19,922,944

_SYSSMU6_1245875459$                             0                327,680                          0

_SYSSMU7_1245875459$                             0             1,114,112                 65,536

_SYSSMU8_1245875459$                             0                458,752            4,849,664

_SYSSMU9_1245875459$                             0             1,179,648                 65,536

10 rows selected.

############## UNDO SPACE USAGE ##############

Segment#      Shrinks     Avg Shrink Size

—————– ————- ———————–

0                0                              0

1                5                2,424,832

2                5                1,402,470

3                6                2,457,600

4                2                  425,984

5                4                1,638,400

6                4                1,523,712

7                2                1,048,576

8                5                2,031,616

9                1                2,621,440

10                2                1,114,112

11 rows selected.

了解并发性信息。有多少并发性事务相互重叠？如果您不断看到高并发的未提交事务，是否自动调整的 retention 正在正确处理工作负载?对于当前未提交的工作，您还可以检查运行时的段活动情况。同时查看 UNDO 改动的信息。这些段的工作负载是否平衡？收缩是否均匀地分布在段中？是否有任何段承受的压力大于其他段？

示例 undostatistics.out

############## RUNTIME ##############

Run Time

—————–

05-09:08

############## Historical V$UNDOSTAT (Last 2 Days) ##############

Query

Maximum                                               Undo     # of                                                     Tuned Ret

Date/Time Minutes   SqlID                 TBS        Blocks    Trans   # of Unexpired    # of Expired Minutes

————- ————- ——————– ———– ——— ———- ——————— —————- —————

03-09:15                 14 0rc4km05kgzb9           14          39       160                        312           25,024                  29

03-09:25                   4 0rc4km05kgzb9           14          36       220                        312           25,024                  43

03-09:35                 14 0rc4km05kgzb9           14         327      200                            8           25,024                  43

03-09:45                   4 0rc4km05kgzb9           14           20      202                        464           24,896                  29

. . .

05-08:37                   1 0rc4km05kgzb9           14           22      195                           80          25,344                  15

05-08:47                12 0rc4km05kgzb9            14           35      216                           48          25,376                  15

05-08:57                  2 0rc4km05kgzb9            14           33      183                           56          25,368                  15

 

284 rows selected.

############## RECENT MISSES FOR UNDO (Last 2 Days) ##############

no rows selected

no rows selected

############## AUTO-TUNING TUNE-DOWN DATA ##############

######## ROLLBACK DATA (Since Startup) ##############

Name                                                                                                        Counters

————————————————————————————- ————

user rollbacks                                                                                                 4,959

transaction tables consistent reads – undo records applied                          3

transaction tables consistent read rollbacks                                                    0

data blocks consistent reads – undo records applied                          300,730

rollbacks only – consistent read gets                                                       11,384

cleanouts and rollbacks – consistent read gets                                             39

rollback changes – undo records applied                                                18,529

transaction rollbacks                                                                                       190

total number of undo segments dropped                                                         0

tune down retentions in space pressure                                                           0

global undo segment hints helped                                                                     1

global undo segment hints were stale                                                               0

local undo segment hints helped                                                                       0

local undo segment hints were stale                                                                  0

undo segment header was pinned                                                             90,532

IMU CR rollbacks                                                                                           6,183

SMON posted for undo segment recovery                                                       0

SMON posted for undo segment shrink                                                            0

18 rows selected.

############## Long Running Query History ##############

 

Date                    SQL ID                Runaway SQL ID                          Space Issues

——————– ———————- —————————————– ————————————————

02-19:05              0rc4km05kgzb9                                                          Max Tuned Down – Not Auto-Tuning

02-19:15              0rc4km05kgzb9                                                          Reached Best Retention

02-19:25              0rc4km05kgzb9                                                          Reached Best Retention

02-19:35              0rc4km05kgzb9                                                          Reached Best Retention

02-19:45              0rc4km05kgzb9                                                          Reached Best Retention

############## Details on Long Run Queries ##############

SQL ID                 SQL Text                                                                                             Last Load                  Elapsed Days

———————- ——————————————————————————— ————————– ——————

0rc4km05kgzb9    select 1 from obj$ where name=’DBA_QUEUE_SCHEDULES’  2009-08-04/13:30:06                     19

查看报告中在设定时间内收集的关于 undo 活动的数据（默认为 2 天）。

第二部分将显示在 V$UNDOSTAT 中的七天或在实例生命周期中，查询持续时间大于调整后的Retention时间的情况。

是否有大量的“调低”相关活动？“调低”是自动调整 AUM 的一种功能，将会收缩保留时间以减少 UNDO 空间压力。这可指向尚未引发 ORA-30036 错误的空间问题。

最后调查长时运行查询数据。这些可能是我们预期内的，但也有助于指出意外的查询活动。

  1. 等待/锁定分析

示例 undopressure.out

############## RUNTIME ##############

Run Time

—————–

05-08:58

############## WAITS FOR UNDO (Since Startup) ##############

Cummalitve

Instance# Enq Total Requests   Total Waits       Successes           Failures             Time

————- —— ——————– —————- ———————— ————— ——————

1                 HW                  2,104                     0                       2,104                    0                       0

1                  US                        58                     0                            58                    0                       0

############## LOCKS FOR UNDO ##############

no rows selected

############## TUNED RETENTION HISTORY (Last 2 Days) ##############

############## LOWEST AND HIGHEST DATA ##############

END_TIME TUNED_UNDORETENTION

—————– ————————————–

05-08:58                                                      900

05-08:57                                                      900

05-08:37                                                      900

05-07:17                                                      900

05-04:17                                                      900

05-03:57                                                      900

05-03:37                                                      900

05-02:57                                                      900

05-02:37                                                      900

05-02:17                                                      900

05-01:17                                                      900

11 rows selected.

END_TIME TUNED_UNDORETENTION

—————– ————————————-

04-17:57                                                   2227

############## CURRENT TRANSACTIONS ##############

START_DATE  START_SCN   STATUS            SQL Code

——————— —————— —————- —————————————-

05-08:58               53717782         ACTIVE       update abc_tmp set edition_name=”

CURRENT_SCN

———————

53734654

############## WHO’S STEALING WHAT? (Last 2 Days) ##############

UnexStolen ExStolen UnexReuse ExReuse

————— ———— ————— ———–

0              22                   0              0

0              12                   0              0

查看等待和锁定信息。高等待和性能问题可能与已知的 UNDO 性能 bug 匹配。同时查看高、低调整后的Retention信息。在此报告中，您是否发现被盗 extent 的证据？未过期 extent 是否被盗？

  1. 调查 LOB 问题

示例 lobdata.out

Table               Column                                                Tablespace       PCTVersion %   Retention

—————— ———————————————- ——————– ——————– ————-

CTEST             DATA_OBJECT                                TB1                                                          900

PAA_TEST    RESPONDER_COMMENT              TB1                                                          900

EMP_O           PICTURE                                             USERS                                      10

EMP_O           RESUME                                             USERS                                      10

TEST               COMMENTS                                      TB1                                                          900

5 rows selected.

如果定期更新 LOB 数据，LOB 对象上发生 ORA-1555 就可能是预期内的。PCTVersion 默认为 10%，如果您持续对 LOB 数据进行了更改，那么这个此值通常需要调高很多。有时 100%（保留所有更改）还不足以适应工作负载。常规的 ORA-1555 诊断/分析对与 LOB 相关的 ORA-1555 错误是没有用的。LOB 产生的 UNDO 不是使用 UNDO 表空间中的 extent，而是保留在 LOB 表空间中。

其他参考：
https://wenku.baidu.com/view/47b01e6ab84ae45c3b358ca8.html

https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams222.htm#REFRN10225

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=341463354078393&parent=DOCUMENT&sourceId=1307334.1&id=1555.1&_afrWindowMode=0&_adf.ctrl-state=wgqt71fpl_126

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=341423607535564&id=1307334.1&_afrWindowMode=0&_adf.ctrl-state=wgqt71fpl_77

Oracle 标准服务 – 数据库技术支持通讯 – 2015年11月版，57期 (文档 ID 2088997.1)

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=wgqt71fpl_299&_afrLoop=344990618186201#title1

转载文章（档）

关于ORACLE的v$process 和v$session 到达最大连接限制的问题

留下评论

ORA-12520：TNS:监听程序无法为请求的服务器类型找到可用的处理程序

oracle这个错误的意思是  数据库的连接数达到最大值限制。

一、关于v$process 和v$session的基本知识
Oracle数据库中Session和Connection的区别。
在Oracle的官方文档上，对Session和Connection是这样解释的：
  Connection: Communicate pathway between a client process and an Oracle database instance.

连接：一个客户端进程和Oracle数据库实例之间的通信链路。

Session: A logical entity in the database instance memory that represnts the state of a current user login to a database. A single connection can have 0, 1 or more sessions established on it.
会话：用于展示当前登录到数据库用户的状态的数据库实例内存中的一个逻辑实体。一个单独的连接可以有0，1，或者更多的会话。

Connection并不是直接建立在用户进程和数据库实例之间的。而是在用户进程和Server Process（服务器进程）之间的，因此有一个Connection就一定会有一个用户进程和一个服务器进程。但不一定会存在Session。比如，如果需要将东西从A运到B，Connection可以看成是一座“桥”，而卡车把东西从A运到B后并返回A，这就是Session。所以，只要不断开连接，随时都可以在这个连接上创建出会话。

二、查看v$process 和v$session的基本信息
查询资源限制的视图的语法：

select * from v$resource_limit;

select * from v$process;

select * from v$session;

select * from v$session t where t.STATUS=’ACTIVE”;

process和session参数最大值估算方法
select round(sum(pga_used_mem)/1024/1024,0) total_used_M, round(sum(pga_used_mem)/count(1)/1024/1024,0) avg_used_M,
round(sum(pga_alloc_mem)/1024/1024,0) total_alloc_M, round(sum(pga_alloc_mem)/count(1)/1024/1024,0) avg_alloc_M from v$process;

三、释放资源
在sqlnet.ora文件中设置expire_time 参数。
可以使用EXPIRE_TIME参数间歇检查异常session并释放process。
官方说明：SQLNET.EXPIRE_TIME
Purpose
Use parameter SQLNET.EXPIRE_TIME to specify a the time interval, in minutes, to send a probe to verify that client/server connections are active. Setting a value greater than 0 ensures that connections are not left open indefinitely, due to an abnormal client termination. If the probe finds a terminated connection, or a connection that is no longer in use, it returns an error, causing the server process to exit. This parameter is primarily intended for the database server, which typically handles multiple connections at any one time.
Limitations on using this terminated connection detection feature are:
It is not allowed on bequeathed connections.
Though very small, a probe packet generates additional traffic that may downgrade network performance.
Depending on which operating system is in use, the server may need to perform additional processing to distinguish the connection probing event from other events that occur. This can also result in degraded network performance.

Recommended Value
10
Example
SQLNET.EXPIRE_TIME=10

这里设置是10分钟，每10分钟Oracle会确认所有session客户端连接是否正常，对于不正常的session，oracle会清理process。

同时，扩大最大连接数，同时Session自动跟着扩大。

–修改最大连接数:

alter system set processes = 500 scope = spfile;

重启数据库：

cmd :sqlplus sys/passw@databasename as sysdba

然后输入以下命令

shutdown immediate;——关闭数据库，大概需要一个小时

startup;–重启数据库，大概几分钟。

重启之后：

select count(*) from v$process    ——从298变成132

select count(*) from v$session    ——从104变成38

但是，在ArcGIS Portal 里面打开一个页面，调用了SDE图层，

上面的连接数字都增加，那么就算设置为最大500，也支撑不来多少用户使用的！！！！？？？？

–查看当前有哪些用户正在使用数据

SELECT osuser, a.username,cpu_time/executions/1000000||’s’,b.sql_text,machine

from v$session a, v$sqlarea b

where a.sql_address =b.address order by cpu_time;

——在ArcGIS Portal 里面打开一个页面，调用了SDE图层，通过以上语句，可以看到SDE用户的连接信息。

就算关闭了浏览器，一段时间依然可以看到这些信息，半个小时后，SDE的连接才消失。

——查询数据库有没有死锁，no row selected 说明没有死锁。

select * from v$locked_object

经验闲谈

Oracle R12.2补丁步骤

留下评论

–应用层应用补丁
–1、补丁准备阶段（需run模式下）,合适之前补丁是否正常并将文件清理干净,同时同步FS1和FS2
$ adop phase=prepare

–2、补丁应用阶段
$ adop phase=apply patches=xxxxxx

–3、确定阶段（编译无效对象,在此前阶段可通过abort回退）
$ adop phase=finalize

–4、切换阶段（关闭并发管理器和应用,置EBS系统不可用,并完成转化）
$ adop phase=cutover

–5、清理阶段（run模式下,删除代码和数据,如未运行或者下次prepare阶段自动运行）
$ adop phase=cleanup

参考文件：

How To Run Adop Like – Adpatch – With Option Apply=No? (文档 ID 2067371.1)
ADOP phase=prepare Errors With patch does not exists (文档 ID 1941327.1)

技术笔记（小潘的技术记录博客）