Search results for: “cost”

  • 什么是Joint Escalation Team?

    什么是Joint Escalation Team? Joint Escalation Team也可以简写为JET。JET是指当客户采用了多种软件供应商的产品搭建系统后, 系统所发生的问题通过单独的某一个供应商无法解决,需要集合多个供应商的技术力量解决, 这个时候就需要组成Joint Escalation Team,从而避免陷入孤军奋战。 Joint Escalation Team可以由客户自己牵头,也可以由首先接到服务请求的供应商来主导。 假设说我们使用IBM AIX+Oracle的组合,在系统搭建或运行过程中遇到了问题,技术人员可能首先 提交Service Request给Oracle的MOS,Oracle GCS经过一番分析之后发现问题在同一个Oracle版本的 其他平台上均无法重现,而仅在与特定的AIX版本组合时被触发,那么因为Oracle与IBM之间存在Engagement 合约关系, 所以Oracle Support员工可能会提交一个内部SR要求IBM的技术力量加入,以组成Joint Escalation Team来解决问题。 一般来说当我们的问题上升到需要JET来解决的地步时,那么很难奢望该问题在短期内能有solution了, 这要求我们有足够的耐心。所以如果真的遇到这样的问题,那么我更建议你通过一些workaround的方式来绕过障碍。 已知与Oracle存在Joint Escalation Team Engagement 关系的厂商包括: HP、Redhat、Dell、EMC、IBM等。 了解更多oracle support和JET的信息: [gview file=”http://www.oracle.com/us/support/library/oracle-premier-support-brochure-069189.pdf”]   “Support for the Complete Technology Stack The necessary complexity of today’s IT environments often makes it difficult to…

  • [转]BUFFER SORT是BUFFER却不是SORT

    用AUTOTRACE查看执行的计划的同学常问到执行计划里的BUFFER SORT是什么意思,这里为什么要排序呢? BUFFER SORT不是一种排序,而是一种临时表的创建方式。 BUFFER是执行计划想要表达的重点,是其操作: 在内存中存放一张临时表。 SORT修饰BUFFER,表示具体在内存的什么地方存放临时表: 在PGA的SQL工作区里的排序区。 至少有一种方法可以说服对此表示怀疑的人们,就是查询V$SQL_PLAN_STATISTICS_ALL.PROJECTION字段。 将STATISTICS_LEVEL设置为ALL先,然后执行真-排序命令,比如:select hire_date,salary from hr.employees order by hire_date 然后查看其V$SQL_PLAN_STATISTICS_ALL.PROJECTION字段: SYS@br//scripts> select projection from v$sql_plan_statistics_all where sql_id=(select sql_id from v$sql where sql_text=’select hire_date,salary from hr.employees order by hire_date’) and operation=’SORT’ and options=’ORDER BY’; PROJECTION —————————————————————- (#keys=1) “HIRE_DATE”[DATE,7], “SALARY”[NUMBER,22] 1 row selected. 其中开头的#keys表示返回的结果中排序的字段数量。 再执行一句真-排序命令:select hire_date,salary from hr.employees order by…

  • 了解DBMS_OUTPUT包

    DBMS_OUTPUT程序包是我们在Oracle开发过程中常用的一个包体,使用该包我们可以从存储过程、包或触发器发送信息(messages)。Oracle推荐在debug PL/SQL程序时使用该程序包,不推荐使用该包来做报表输出或其他格式化输出之用。 概述 DBMS_OUTPUT包主要用于调试PL/SQL程序,或者在SQL*PLUS命令中显示信息(displaying message)和报表,譬如我们可以写一个简单的匿名PL/SQL程序块,而该块出于某种目的使用DBMS_OUTPUT包来显示一些信息。 在该DBMS_OUTPUT包中存在2个存储过程,它们是PUT_LINE和PUT过程,使用这2个Procedure可以做到将信息存放到PL/SQL的Buffer中,以便其他的触发器、存储过程、程序包来读取。在独立的PL/SQL程序或匿名块中,我们还可以使用GET_LINES和GET这2个存储过程来将存放在PL/SQL Buffer中的信息输出(display)到屏幕。 如果该DBMS_OUTPUT包被禁用了,那么所有对其子程序(subprogram)的调用都将被忽略。这样用户可以设计应用程序,仅在客户端程序能够处理这些信息的时候启用这些子程序。 安全模型 必须使用SYS用户运行$ORACLE_HOME/rdbms/admin/dbmsotpt.sql,该脚本会为DBMS_OUTPUT创建同义词,并将该包的执行权限赋予PUBLIC角色。 操作提示 若不调用GET_LINE函数,或者不在SQL*PLUS中将信息(information)输出到屏幕的话,那么缓存的信息(buffered message)最终将被忽略。 SQL*PLUS会在SQL语句或匿名PL/SQL块调用结束后调用GET_LINES过程 在SQL*PLUS中输入SET SERVEROUTPUT ON,将启动下面语句的效果: DBMS_OUTPUT.ENABLE (buffer_size => NULL); 输出不再有限制(no limit on the output) 不推荐在应用程序代码中调用ENABLE或DISABLE过程,因为这将导致如SQL*PLUS这种外部工具无法正常控制输出与否。 注意使用DBMS_OUTPUT传送的message在实际执行该DBMS_OUTPUT的子程序或触发器执行完成之前都不会实际被发送。这也就导致了在整个运行过程中不会有信息被写出,所以用DBMS_OUTPUT包做日志输出的话只能等到整个子程序结束才会有日志出现。 程序异常 DBMS_OUTPUT子程序可能引发ORA-20000错误,同时其OUTPUT存储过程可能返回以下错误: DBMS_OUTPUT 可能遇到的错误 错误号 描述 ORU-10027: Buffer缓存溢出 ORU-10028: 行长溢出 规则和限制 最大的单行长度是32767 bytes字节 默认的buffer大小时20000 bytes字节,最小的buffer为2000 bytes字节,最大没有限制 使用示例 示例1:在触发器生成输出 我们可以使用一个触发器来打印正在调试进程的一些信息,譬如你可以在触发器中调用以下代码: DBMS_OUTPUT.PUT_LINE(‘I got here:’||:new.col||’ is the new value’); 若启用了DBMS_OUTPUT包,那么由PUT_LINE所生成的文本将被缓存到Buffer中,之后我们可以通过以下代码获取该Buffer中的信息:…

  • Script:Diagnostic Oracle Locks

    以下脚本可以用于诊断Oracle实例中的锁情况(Lock Status): REM SCRIPT: FULLY DECODED LOCKING set echo off set lines 200 set pagesize 66 break on Kill on sid on  username on terminal column Kill heading ‘Kill String’ format a13 column res heading ‘Resource Type’ format 999 column id1 format 9999990 column id2 format 9999990 column locking heading ‘Lock Held/Lock Requested’ format a40…

  • Index block split等待事件

    When a request for rows from a table is issued, Oracle may determine through the cost-based optimizer, which index access path is best for finding rows in a table. During this index lookup process, if another session is inserting or updating data, which causes updates to that index and an index block split, the first…

  • db file scattered read等待事件

    Oracle中db file scattered read等待事件发生在当一个会话在等待一个多数据块的IO请求完成。其典型的发生在当有全表扫描和索引快速扫描INDEX FAST FULL SCAN时。Oracle一次性读取DB_FILE_MULTIBLOCK_READ_COUNT对应的连续数据块,并将它们分散到buffer cache中的buffer中。 换句话说从IO读取上和物理存储的顺序上这些数据块应当是连续的,一个块排在一个块后面,但从buffer cache角度看这些数据块对应的buffer并不连续在一起。   具体的行为当然也和操作系统版本以及oracle版本相关,以及不同的存储设备特性都会有关系。 该db file scattered read等待的相关参数: p1 file#  这是db file scattered read读取的数据块所在的数据文件文件号,从Oracle 8开始是绝对数据文件号ABSOLUTE file number (AFN)。 p2 block# 这是db file scattered read读取的起始数据块号 p3 blocks 这是db file scattered read读取的块的数量,最大为DB_FILE_MULTIBLOCK_READ_COUNT,从Oracle 10.2开始该参数会自动调优。   db file scattered read的等待时间 是直到所有数据块的IO请求都被满足。注意操作系统可能基于文件系统缓存来满足这些IO请求,对于Oracle来说 起始它并不知道这些IO请求是从文件系统缓存返回的,还是真的左了磁盘的读取操作或存储响应返回的,它只负责做read() pread()这些操作系统系统调用而已。   Waits on this event indicate the statement is performing…

  • db file parallel read等待事件

    The process has issued multiple I/O requests in parallel to read blocks from data files into memory and is waiting for all requests to complete. This occurs during regular activity when a session batches many single block I/O requests together and issues them in parallel. This is also occurs during recovery. This wait event does…

  • cell multiblock physical read等待事件

    This is an Exadata wait event similar to ‘db file scattered read’ and typically indicates the statement is performing a full table scan or an index fast full scan. This wait event is not seen nearly as much as ‘db file scattered read’ is seen on non-Exadata platforms because many full scans are offloaded to…

  • Reduce the Number of SQL Statements

    Shareable SQL uses bind variables rather than literal values. If an application makes use of literal (unshared) SQL then this can severely limit scalability and throughput. The cost of parsing a new SQL statement is expensive both in terms of CPU and the number of times the library cache and shared pool latches may need…

  • cursor_sharing=’SIMILAR’将被废弃

    根据metalink文档<ANNOUNCEMENT: Deprecating the cursor_sharing = ‘SIMILAR’ setting [ID 1169017.1]>在11g中将逐渐废弃cursor_sharing参数的SIMILAR选项,原因是在今后的版本中Exact和Force选项可以满足游标共享的需求了,使用SIMILAR选项可能引发额外的version_count过多或cursor pin s on X等待事件。 We recommend that customers discontinue setting cursor_sharing = SIMILAR due to the many problematic situations customers have experienced using it. The ability to set this will be removed in version 12 of the Oracle Database (the settings of EXACT and FORCE will remain available).…