linux运行oracle11g后很慢怎么优化

1 标准优化：遵从Oracle技术文档中的说明tune你的Linux，比如共享内存等等。这里不赘述了，因为文档中很全。 2 根据你的使用情况采取Dedicate型或MTS型数据库。具体方法也看文档。 3 假如你不是对数据库中的java应用非凡有需求的话，不要装它，也不要启动它。（假如你装了的话） 4 对你的服务器来说，最好专用。假如你不专用，说明你对性能并不那么敏感，也用不着优化了。 5 内存越大越好。但Linux对内存大小有限制，因此需要去找一些Patch。 6 下载一个SGI's POSIX Asynchronous I/O and Raw I/O的内核Patch。它能大幅度提高你数据文件的访问速度。 7 假如你采用ext2文件系统，把Block的大小增加到4~8KB。其中dbf所在分区的大小最少弄到8192KB。 8 尽可能用SCSI硬盘。假如是IDE的，好好调调参数。 9 这里是一个示例程序: set -a VM=/PRoc/sys/vm BDFLUSH="40 1024 64 256 500 3000 500 1884 2" BUFFERMEM="5 8 10" FREEPAGES="512 1024 3072" OVERCOMMIT="1" case $1 in start) echo "$BDFLUSH">$VM/bdflush echo "$BUFFERMEM">$VM/buffermem echo "$FREEPAGES">$VM/freepages echo "$OVERCOMMIT">$VM/overcommit_memory /sbin/hdparm -k -u 1 -m 32 -c 1 /dev/hda; /sbin/hdparm -k -u 1 -m 16 -c 1 /dev/hdc; ;; stop) toUCh /root/shouldnthappen; ;; ) echo "USAGE $0 {startstop}"; ;; esac; 10 假如你有Solaris for X86的话，可以运用它的分区工具把你的所有分区都改成UFS。Linux的当前Kernel是支持UFS的。在数据库运用上，UFS比ext2好。 11 假如可能，应该采用诸如IBM JFS或SGI XFS这样的64位文件系统。

进行连接本地ORACLE数据库m_pConnection-> ConnectionString =

"Provider=OraOLEDBORACLE1;

Data Source=jiey;

User Id=system;

Password=manager; ";

m_pConnection-> Open( " ", " ", " ",adConnectUnspecified );

这部分整个运行期只做一次，连接是很费时间的，不要总是open

如果不需要查看数据就不要m_pRecordset-> Open了

直接用m_pConnection执行SQL语句插入

我想这样会快很多

详解cursor: pin S wait on X等待事件

‘cursor: pin events’等待事件

该类等待事件一般是为了pin相关的子游标

‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享 *** 作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。

实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。

下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:

过多的子游标 High Version Counts

过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。

检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA

昂贵的X$、V$视图查询

一些对于V$、X$视图的查询，需要访问X$KGL之类的fixed table，可能触发Mutex争用。

Mutex持有者得不到CPU

Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。

这种情况可能由于OS *** 作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。

已经被KILLED的SESSION仍持有Mutex

当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。

举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。

如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!

1 首先看看，先分析慢的原因，一部分是因为循环次数多，一部分是因为查询数据量大慢。

2 可以从优化查询入手，比如某次查询的sql里面的数据，条件字段没有建索引，导致了全表扫描，

是不是 只需要几个字段，但是你写了 select 等等，总之要优化数据的速度。

2 可以从循环逻辑看起，有些循环可能是不必要的，能不能通过条件查询来替代循环，总之要从逻辑上优化代码

希望可以帮到你

当在 Oracle Database 10g 中回滚长期运行的事务时，无论是并行实例恢复会话还是用户执行的回滚语句。您所需做的一切就是查看视图 V$SESSION_LONGOPS 并评估还需要多少时间。

项目中该数据库每月定期要导入大量数据。通过对导入数据期间LGWR switch出现频率的观察，发现LGWR switch切换过于频繁，需要对redo File进行优化，建议设置16个group，每个group member大小为200M。

另外，需要对导入脚本进行优化，

imp dw/cnfj_bts_dw file=call_gaa_551_200906dmp full=y ignore=y feedback=50000 buffer=10240000 commit=y indexes=n log=’/home/imp200909log’;附录：

1、停止并行回滚，减少IO请求，快速提升系统响应能力

如果你没时间等待回滚进程完成回滚 *** 作，可根据如下提示进行 *** 作。

最后在google上根据ora_p001, wait for a undo record 的关键字，找到了一些信息，以下信息引起了我的注意：

Oracle工程师首先怀疑是临时表空间空间不足导致，经检查临时表空间没有空间不足的情况，仔细观察日志发现重做日志文件不断切换，分析应该是有较多的事务没有完成提交或者有较多没有提交的事务完成回滚。现在面临的问题是我们没有很多时间去等待所有的事务去完成回滚或提交。解决问题的思路就是如何尽快结束这些事务的回滚或提交。

1) 查看spfile文件中是否有fast_start_parallel_rollback参数的设置，检查结果G网数据库没有设置该参数。如果没有显式设置，则该参数的默认值为low。修改该参数值为false

2) 将数据库启动到nomount状态：startup nomount

　3) 修改改参数值：alter system set fast_start_parallel_rollback = FALSE scope=spfile

4) shutdown immediate关闭数据库

5) startup启动

6) 查看该参数是否生效：show parameter fast_start_parallel_rollback

7) 等待一段时间

8) shutdown immediate数据库可以关闭

1、是这样的。

2、这个说不好，我没这么做过。你手边应该有oralce的全套电子文档吧。关键是你要找对系统表或者视图。我记得索引的系统视图不是这个。

3、这些与你要做的有关系吗？别像没头苍蝇一样瞎撞了。

4、不用删表，如果你连基本的语句命令都不懂，那只能看书了。

5、慢的原因有好多，逐步排除吧，等找到真正原因再说。急没用的。

6、默认情况下，是会建到用户的默认表空间的。

7、这个看你的维护需要。最起码先弄明白你的库是怎么回事再说吧。就从这些问题看，你根本就是门外汉，连库是怎么回事都没弄明白。

以上就是关于linux运行oracle11g后很慢怎么优化全部的内容，包括:linux运行oracle11g后很慢怎么优化、oracle 客户端打开数据库缓慢的问题、oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！