一次丧心病狂的PLS-00306错误分析-mysql教程-PHP中文網

首頁

資料庫

mysql教程

一次丧心病狂的PLS-00306错误分析

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 04:36 PM

dat分析錯誤

在做database replay预处理的时候遇到一个问题，初略的看，是执行包调用内部(函数/存储过程)出现的错误。感觉是一个典型的传参的错误。 SQL exec dbms_workload_replay.PROCESS_CAPTURE('AAA');BEGIN dbms_workload_replay.PROCESS_CAPTURE('AAA'); END; *ER

在做database replay预处理的时候遇到一个问题，初略的看，是执行包调用内部(函数/存储过程)出现的错误。感觉是一个典型的传参的错误。

SQL> exec dbms_workload_replay.PROCESS_CAPTURE('AAA');
BEGIN dbms_workload_replay.PROCESS_CAPTURE('AAA'); END; 
*
ERROR at line 1:
ORA-06550: line 1, column 15:
PLS-00306: wrong number or types of arguments in call to 'ADD_CAPTURE'
ORA-06550: line 1, column 9:
PL/SQL: Statement ignored
ORA-06512: at "SYS.DBMS_WORKLOAD_REPLAY", line 2301
ORA-06512: at line 1

这种问题，一般我们都会做10046 trace进一步看调用了那个函数引起的问题。从trace中看到是在运行dbms_wrr_internal.add_capture出的问题。

BEGIN   :1 := dbms_wrr_internal.add_capture( :name,                                        :db_id,                                        :db_name, 
                              :db_version,                                        'tmp',                                        '/tmp', 
                  'TRUE',                                        :status,                                        NULL, 
NULL,                                        :stime,                                        NULL,                                        :sscn, 
                           :dflt_action,                                        NULL,                                        NULL, 
             :wid,                                        :internal_stime                                      ); END; 
END OF STMT 
PARSE #11529215044979176000:c=0,e=540,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=434859905841 
===================== 
PARSING IN CURSOR #11529215044979172808 len=8 dep=1 uid=0 oct=45 lid=0 tim=434859906846 hv=2761672982 ad='0' sqlid='8sst43uk9rk8q' 
ROLLBACK 
END OF STMT 
PARSE #11529215044979172808:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=0,plh=0,tim=434859906844 
XCTEND rlbk=1, rd_only=1, tim=434859906921 
EXEC #11529215044979172808:c=0,e=33,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=0,plh=0,tim=434859906939 
CLOSE #11529215044979172808:c=0,e=2,dep=1,type=3,tim=434859906960 
PARSE #11529215044979172808:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=0,plh=0,tim=434859907039 
XCTEND rlbk=1, rd_only=1, tim=434859907062 
EXEC #11529215044979172808:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=0,plh=0,tim=434859907074 
CLOSE #11529215044979172808:c=0,e=1,dep=1,type=3,tim=434859907091 
EXEC #11529215044981457272:c=10000,e=77698,p=0,cr=60,cu=29,mis=0,r=0,dep=0,og=1,plh=0,tim=434859907137 
ERROR #11529215044981457272:err=6550 tim=434859907154
SQL> desc dbms_wrr_internal 
FUNCTION ADD_CAPTURE RETURNS NUMBER 
Argument Name                  Type                    In/Out Default? 
------------------------------ ----------------------- ------ -------- 
NAME                           VARCHAR2                IN 
DB_ID                          NUMBER                  IN 
DB_NAME                        VARCHAR2                IN 
DB_VERSION                     VARCHAR2                IN 
DIR                            VARCHAR2                IN 
DPATH                          VARCHAR2                IN 
DPATH_SHARED                   VARCHAR2                IN 
STATUS                         VARCHAR2                IN 
ECODE                          NUMBER                  IN 
EMSG                           VARCHAR2                IN 
STIME                          DATE                    IN 
ETIME                          DATE                    IN 
SSCN                           NUMBER                  IN 
DEFAULT_ACTION                 VARCHAR2                IN 
AWR_DB_ID                      NUMBER                  IN 
AWR_BSNAP                      NUMBER                  IN 
WID                            VARCHAR2                IN
SQL> select NAME,DATATYPE_STRING,VALUE_STRING from v$sql_bind_capture where sql_id='3h55aw49j63g8'; 
no rows selected

本来以为10046能够把绑定变量这些数值抓出来，但是这里确没有，v$sql_bind_capture也抓不到绑定变量的值。我怀疑和内部的包有关系。所以我们无从判断是哪一个参数的调用类型出了问题。遇到这样的问题也没什么好的办法，以前在自己的Linux环境上搞过database replay，是能够成功的，所以想法就是把Linux上环境的这个包迁移到Hp环境上在试试。于是就用grep去搜索具体是那个文件。搜到了文件名为"prvtwrr.plb"的文件，里面是一堆加密的东西。把这个文件传到HP上运行，运行完后发现，妹的还是报以前的错误。郁闷啊，为什么在我Linux上的环境就可以了，在HP的环境就不行了。走投无路的时候，同事在$ORACLE_HOME目录下面执行了下列命令。

w4sd23pa#[/home/oracle]find $ORACLE_HOME -name "prvtwrr.plb" 
/oracle/app/oracle/product/11.2.0/db_1/rdbms/admin/prvtwrr.plb 
/oracle/app/oracle/product/11.2.0/db_1/.patch_storage/17411249_Apr_21_2014_22_29_21/files/rdbms/admin/prvtwrr.plb 
w4sd23pa#[/home/oracle] 
w4sd23pa#[/home/oracle]ls -l /oracle/app/oracle/product/11.2.0/db_1/rdbms/admin/prvtwrr.plb 
-rw-r--r--   1 oracle     oinstall    151611 Apr 22 13:29 /oracle/app/oracle/product/11.2.0/db_1/rdbms/admin/prvtwrr.plb 
w4sd23pa#[/home/oracle]ls -l /oracle/app/oracle/product/11.2.0/db_1/.patch_storage/17411249_Apr_21_2014_22_29_21/files/rdbms/admin/prvtwrr.plb 
-rw-r--r--   1 oracle     oinstall    149850 Sep 29  2013 /oracle/app/oracle/product/11.2.0/db_1/.patch_storage/17411249_Apr_21_2014_22_29_21/files/rdbms/admin/prvtwrr.plb

执行find命令居然发现能够找到两个文件，而另外一个文件明眼一看就是补丁文件17411249，赶紧用opatch看了一下补丁的情况。发现这个补丁是最近新装的。

w4sd23pa#[/home/oracle]opatch lsinventory 
Oracle Interim Patch Installer version 11.2.0.3.6 
Copyright (c) 2013, Oracle Corporation.  All rights reserved. 
Oracle Home       : /oracle/app/oracle/product/11.2.0/db_1 
Central Inventory : /oracle/app/oraInventory 
   from           : /oracle/app/oracle/product/11.2.0/db_1/oraInst.loc 
OPatch version    : 11.2.0.3.6 
OUI version       : 11.2.0.4.0 
Log file location : /oracle/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/opatch2014-05-27_23-23-16PM_1.log 
Lsinventory Output file location : /oracle/app/oracle/product/11.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2014-05-27_23-23-16PM.txt 
-------------------------------------------------------------------------------- 
Installed Top-level Products (1): 
Oracle Database 11g                                                  11.2.0.4.0 
There are 1 product(s) installed in this Oracle Home. 
Interim patches (18) : 
Patch  17411249     : applied on Tue May 20 18:41:12 GMT+08:00 2014 
Unique Patch ID:  17551033 
   Created on 21 Apr 2014, 22:29:21 hrs PST8PDT 
   Bugs fixed: 
     17411249

看到了这个信息之后，我们就怀疑是不是安装这个补丁出了问题。如果是的话，我们回退了再试试，于是我们把这个补丁做了一个回退，在readme里面看还要运行一个postinstall.sql脚本，回退完成后在执行预处理的操作发现居然成功了。然后我们再一次安装了这个补丁，运行了postinstall.sql脚本，发现预处理还是成功的。后面问了安装补丁的同事，最终发现是他忘记了执行postinstall.sql脚本。总的来说，这个故事还是很丧心病狂的，如果不去执行一把find命令，根本就不会发现是因为安装了新补丁造成的错误。

原文地址：一次丧心病狂的PLS-00306错误分析, 感谢原作者分享。

陳述

本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn

如何識別和優化MySQL中的慢速查詢？（慢查詢日誌，performance_schema）Apr 10, 2025 am 09:36 AM

要優化MySQL慢查詢，需使用slowquerylog和performance_schema：1.啟用slowquerylog並設置閾值，記錄慢查詢；2.利用performance_schema分析查詢執行細節，找出性能瓶頸並優化。

MySQL和SQL：開發人員的基本技能Apr 10, 2025 am 09:30 AM

MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統，SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎，SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢，如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題，可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。

描述MySQL異步主奴隸複製過程。Apr 10, 2025 am 09:30 AM

MySQL異步主從復制通過binlog實現數據同步，提升讀性能和高可用性。 1)主服務器記錄變更到binlog；2)從服務器通過I/O線程讀取binlog；3)從服務器的SQL線程應用binlog同步數據。

mysql：簡單的概念，用於輕鬆學習Apr 10, 2025 am 09:29 AM

MySQL是一個開源的關係型數據庫管理系統。 1）創建數據庫和表：使用CREATEDATABASE和CREATETABLE命令。 2）基本操作：INSERT、UPDATE、DELETE和SELECT。 3）高級操作：JOIN、子查詢和事務處理。 4）調試技巧：檢查語法、數據類型和權限。 5）優化建議：使用索引、避免SELECT*和使用事務。

MySQL：數據庫的用戶友好介紹Apr 10, 2025 am 09:27 AM

MySQL的安裝和基本操作包括：1.下載並安裝MySQL，設置根用戶密碼；2.使用SQL命令創建數據庫和表，如CREATEDATABASE和CREATETABLE；3.執行CRUD操作，使用INSERT,SELECT,UPDATE,DELETE命令；4.創建索引和存儲過程以優化性能和實現複雜邏輯。通過這些步驟，你可以從零開始構建和管理MySQL數據庫。

InnoDB緩衝池如何工作，為什麼對性能至關重要？Apr 09, 2025 am 12:12 AM

InnoDBBufferPool通過將數據和索引頁加載到內存中來提升MySQL數據庫的性能。 1)數據頁加載到BufferPool中，減少磁盤I/O。 2)臟頁被標記並定期刷新到磁盤。 3)LRU算法管理數據頁淘汰。 4)預讀機制提前加載可能需要的數據頁。

MySQL：初學者的數據管理易用性Apr 09, 2025 am 12:07 AM

MySQL適合初學者使用，因為它安裝簡單、功能強大且易於管理數據。 1.安裝和配置簡單，適用於多種操作系統。 2.支持基本操作如創建數據庫和表、插入、查詢、更新和刪除數據。 3.提供高級功能如JOIN操作和子查詢。 4.可以通過索引、查詢優化和分錶分區來提升性能。 5.支持備份、恢復和安全措施，確保數據的安全和一致性。