Oracle ----調節共享服務器

本文介绍如何配置Oracle共享服务器以支持更多并发连接,包括调整大池大小、调度进程数量及共享服务器进程数量的方法。

Oracle共享服務器

Oracle 的並發用戶很多,且每個用戶消耗的服務器資源不多時候,可以把這個oracle 服務器設置成共享服務器,共享服務器對應于專用服務器,是oracle 服務器的一個可選配置。

  實現了不增加物力資源的同時,支持更多的並發用戶連接,通過多個用戶

共享有限的物理資源來實現。

 

Oracle 共享服務器與專用的服務器的連接有很大的不同,專用服務器内用戶的信息在PGA内,而共享用戶會話的信息在UGA内,UGA可以放到共享池内,也可以放到選擇配置的大池内。

 

1:配置共享池大小:

大池的大小應該配置成容納所有共享服務器的連接信息,一般一個連接需要1 MB 3 MB之間的内存空間,可以查詢v$sesstat,v$statname視圖來決定應該配置多大的打池。

 

 

SYS AS SYSDBA on 14-MAR-08 at ORCL>describe v$sesstat;

 Name                                      Null?    Type

 ----------------------------------------- -------- ----------------------------

 SID                                                NUMBER

 STATISTIC#                                         NUMBER

 VALUE                                              NUMBER

 

SYS AS SYSDBA on 14-MAR-08 at ORCL>desc v$statname

 Name                                      Null?    Type

 ----------------------------------------- -------- ----------------------------

 STATISTIC#                                         NUMBER

 NAME                                               VARCHAR2(64)

 CLASS                                              NUMBER

 STAT_ID                                            NUMBER

 

SYS AS SYSDBA on 14-MAR-08 at ORCL>select sum(value) from v$sesstat ss,v$statname st where st.

name='session uga memory max' and ss.statistic#=st.statistic#;

 

SUM(VALUE)

----------

   1007312

 

上面輸出的值顯示一個會話使用的最大UGA内存量是1000 KB左右,如果在這個環境中要支持8個並發連接,那麽就把打池配置成至少1000KB*8=8mb,

在初始化參數内加以下一行,將大池配置成8MB:

Large_pool_size=8mb;

SYS AS SYSDBA on 14-MAR-08 at ORCL>select * from v$sgastat where pool='large pool';

 

POOL         NAME                            BYTES

------------ -------------------------- ----------

large pool   free memory                   8388608

 

2:配置調度個數:

使用v$dispatcher 可以查詢到各個調度進程的情況,這裏利用這個視圖内的信息決定需要配置多少個進程,用以下命令來查詢調度程序的使用情況。

 

SYS AS SYSDBA on 14-MAR-08 at ORCL>select name ,(busy/(busy+idle)*100), busy+idle from v$dispa

tcher;

 

NAME (BUSY/(BUSY+IDLE)*100)  BUSY+IDLE

---- ---------------------- ----------

D000                      0    1105342

 

可以看到進程的使用率很低,如果超過50%,就應該啓動更多的調度進程。

可以使用如下命令將使用TCP網絡協議的調度進程設置成2個。

SYS AS SYSDBA on 14-MAR-08 at ORCL>alter system set dispatchers="(PRO=TCP)(DIS=2)";

 

System altered.

 

3:查看用戶等待調度進程的平均時間

 

SYS AS SYSDBA on 2008-03-14 11:54:31 at ORCL>select decode(sum(totalq),0,'no person wait',sum(

wait)/sum(totalq)) avg_time from v$queue q, v$dispatcher d where q.type='DISPATCHER' and q.pad

dr=d.paddr;

 

AVG_TIME

----------------------------------------

no person wait

 

SYS AS SYSDBA on 2008-03-14 11:57:31 at ORCL>describe v$queue;

 Name                                      Null?    Type

 ----------------------------------------- -------- ----------------------------

 PADDR                                              RAW(4)

 TYPE                                               VARCHAR2(10)

 QUEUED                                             NUMBER

 WAIT                                               NUMBER

 TOTALQ                                             NUMBER

 

SYS AS SYSDBA on 2008-03-14 11:57:46 at ORCL>describe v$dispatcher;

 Name                                      Null?    Type

 ----------------------------------------- -------- ----------------------------

 NAME                                               VARCHAR2(4)

 NETWORK                                            VARCHAR2(128)

 PADDR                                              RAW(4)

 

 

如上,沒有人在等待,如果等待時間持續增大,就要考慮增加調度進程。

 

4:配置共享服務器進程個數

 查看共享服務器數量不足,獲取共享服務器的平均等待時間

 

SYS AS SYSDBA on 2008-03-14 11:58:09 at ORCL>select decode(totalq,0,'no person wait',wait/tota

lq) avg_time from v$queue where type='COMMON';

 

AVG_TIME

----------------------------------------

no person wait

 

如果請求等待的等待時間不斷增大,就需要增加更多的共享服務器進程,用戶可以使用alter system set 修改共享服務器進程個數。

 

SYS AS SYSDBA on 2008-03-14 12:03:47 at ORCL>select * from v$shared_server;

 

NAME PADDR    STATUS             MESSAGES      BYTES     BREAKS CIRCUIT

---- -------- ---------------- ---------- ---------- ---------- --------

      IDLE       BUSY   REQUESTS

---------- ---------- ----------

S000 19CEFE44 WAIT(COMMON)              0          0          0 00

     88635          0          0

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/701141/viewspace-209679/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/701141/viewspace-209679/

内容概要:本文介绍了一个基于多传感器融合的定位系统设计方案,采用GPS、里程计和电子罗盘作为定位传感器,利用扩展卡尔曼滤波(EKF)算法对多源传感器数据进行融合处理,最终输出目标的滤波后位置信息,并提供了完整的Matlab代码实现。该方法有效提升了定位精度与稳定性,尤其适用于存在单一传感器误差或信号丢失的复杂环境,如自动驾驶、移动采用GPS、里程计和电子罗盘作为定位传感器,EKF作为多传感器的融合算法,最终输出目标的滤波位置(Matlab代码实现)机器人导航等领域。文中详细阐述了各传感器的数据建模方式、状态转移与观测方程构建,以及EKF算法的具体实现步骤,具有较强的工程实践价值。; 适合人群:具备一定Matlab编程基础,熟悉传感器原理和滤波算法的高校研究生、科研人员及从事自动驾驶、机器人导航等相关领域的工程技术人员。; 使用场景及目标:①学习和掌握多传感器融合的基本理论与实现方法;②应用于移动机器人、无人车、无人机等系统的高精度定位与导航开发;③作为EKF算法在实际工程中应用的教学案例或项目参考; 阅读建议:建议读者结合Matlab代码逐行理解算法实现过程,重点关注状态预测与观测更新模块的设计逻辑,可尝试引入真实传感器数据或仿真噪声环境以验证算法鲁棒性,并进一步拓展至UKF、PF等更高级滤波算法的研究与对比。
内容概要:文章围绕智能汽车新一代传感器的发展趋势,重点阐述了BEV(鸟瞰图视角)端到端感知融合架构如何成为智能驾驶感知系统的新范式。传统后融合与前融合方案因信息丢失或算力需求过高难以满足高阶智驾需求,而基于Transformer的BEV融合方案通过统一坐标系下的多源传感器特征融合,在保证感知精度的同时兼顾算力可行性,显著提升复杂场景下的鲁棒性与系统可靠性。此外,文章指出BEV模型落地面临大算力依赖与高数据成本的挑战,提出“数据采集-模型训练-算法迭代-数据反哺”的高效数据闭环体系,通过自动化标注与长尾数据反馈实现算法持续进化,降低对人工标注的依赖,提升数据利用效率。典型企业案例进一步验证了该路径的技术可行性与经济价值。; 适合人群:从事汽车电子、智能驾驶感知算法研发的工程师,以及关注自动驾驶技术趋势的产品经理和技术管理者;具备一定自动驾驶基础知识,希望深入了解BEV架构与数据闭环机制的专业人士。; 使用场景及目标:①理解BEV+Transformer为何成为当前感知融合的主流技术路线;②掌握数据闭环在BEV模型迭代中的关键作用及其工程实现逻辑;③为智能驾驶系统架构设计、传感器选型与算法优化提供决策参考; 阅读建议:本文侧重技术趋势分析与系统级思考,建议结合实际项目背景阅读,重点关注BEV融合逻辑与数据闭环构建方法,并可延伸研究相关企业在舱泊一体等场景的应用实践。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值