一直以为在存储过程里面只能通过execute immediate 动态执行SQL语句，没想到朋友今天发来一段代码：CREATE OR REPLACE PACKAGE pkg_testAS    TYPE myrctype IS REF CURSOR;      PROCEDURE get (p_rc OUT myrctype);END pkg_test;/  CREATE OR REPLA

    上文提到从v$Session查看连接数，发现使用连接池后莫名增加了MIN个连接（MIN为连接池的最小连接数）。但是实际上，v$session中看见的连接数是逻辑连接数，并非ORACLE的物理连接。ORACLE的会话与连接甚至可以不相关，允许存在没有物理连接的会话。       因此，仅仅从v$session视图看连接数是不准确的，至于从什么地方可以看见客户端与ORACLE的确切连接数。目前

    PROC的批量操作的时候，与其绑定的数组变量要注意两个问题：1、如果是字符数组， eg: char UserName[1000][41];   使用前先将数组的内容初始化成0x20,  eg:  memset(UserName, 0x20, sizeof(UserName));   否则插入或更新的时候总有些记录出错。2、PROC不支持long long类型的绑定，使用double代替。强

    Pro*C中批量读取游标中的数据的时候，需要注意：最后一次批量读取游标中的数据的时候，数据被取到HostArray中，同时sqlca.sqlcode被置为1403(NO_DATA_FOUND)。如果在fetch后立即判断sqlca.sqlcode的话，可能就导致最后一次的数据取不到。       保险的办法是定义一个变量记录上次的读取条数：if (sqlca.sqlcode==1403 &

测试发现，Pro*C中，不管ORACLE数据库中的number字段是多大，只要字段的值大于绑定的变量所能够容纳的范围，就会出现“ORA-01455: 转换列溢出整数数据类型”。不过，Pro*C不支持long long(64位)类型的绑定。当number字段的值大于2147483647或小于- 2147483648时，建议使用double类型来绑定，然后再将double类型转换成long lon

    使用PL/SQL DEVELOPER 7连接某新装的ORACLE数据库服务器的时候，总是频繁发生ORA-01460错误：类型转换错误。   发现SQL NAVIGATOR很好，就只有PL/SQL DEVELOPER有这个问题。   怀疑是字符集的问题，查了很多资料后定位到了问题的原因：查询select * from nls_database_parameters，查看NLS_CHARACT

    为了测试应用程序的健壮性，故意对正常连接的Pro*C应该程序进行了中断，从而观察它们的表现。 测试的方法为：1、在编译Pro*C应用的时候加上cpool=no或cpool=yes，测试有连接池和没连接池的不同表现；2、启动应用程序后等待输入，将流程挂起；3、在数据库中查询此测试程序的SESSION：

    ORACLE中如果使用了连接池，则v$session中显示的是“物理连接数+逻辑连接数”。    可以通过以下查询区分连接池的连接和非连接池的连接：--连接池连接：SELECT * FROM v$session WHERE program=TestConnPool.exe AND server=DEDICATED;--Server属性标记为DEDICATED(专用) 的连接为连接池

    近几日开始，应用程序频繁出现ORA-21500错误。而且产生错误的原因是随机的。应用程序发生core dump后，栈的信息也是不清晰的，完全不知道到底是应用程序本身的问题还是ORACLE的问题。   ORACLE的文档里是这样描述ORA-21500的：ORA-21500 internal error code, arguments: [string], [string], [string]

    请注意看以下代码中的两条横线中的代码：void TestIf()...{    EXEC SQL BEGIN DECLARE SECTION;    sql_context ctx;    struct sqlca sqlca;    struct ConnectionInfo conn;    int n = 0;    int bln_value = 0;    EXEC SQ

    两天前写的一篇文章提到公司的应用程序常常出现ORA-21500错误（http://blog.youkuaiyun.com/ah__fu/archive/2008/04/16/2296641.aspx），在网上找了很久，终于有以下资料提供了些头绪：http://www.dbatools.net/doc/bug10204.html     Bugs fixed in the 10.2.0.4 Patch

    最近尝试了一下Oracle9i 中 PRO*C的连接池功能，结过越搞越糊涂：1、首先，在proc的编译参数中加上以下选项：      threads=yes   使用多线程      cpool=yes       使用连接池      cmax=6           最多6个连接      cmin=4            最少4个连接      cincr=1           

     公司的业务系统中存在一个大的日志表，表大约是这样：create table log(    logtime date,  -- PK    username varchar2(20));    现有需求如下：统计日志表中，两小时内使用过系统的用户在三天内的日志数。    最初编写的查询如下：WITH    result1 AS    (        SELECT DISTINC

  在偶然一次执行Oracle 9i的left outer join查询时，发现了一些匪夷所思的问题，在此贴出来和大家讨论一下。先创建一些表和记录来模拟当时的情况： create table temp_test1 (        a num

一些SQL的小技巧 工作中总结了一些SQL的技巧，请大家看看 1、CASE中使用范围   我写了这样的一个查询： SELECT CASE Avalue     WHEN Avalue = 0 THEN ‘没数据’

   做一个统计报表的时候，用户要求按星期统计。   于是写了一个函数，得到一个星期一到星期天的时间范围的字符串：create or replace function GetWeekRange(Input IN Date) return varchar2 is    temp number(10);begin    temp := 7-mod(Floor(trunc(Add_months(sysd

    用惯了SQLSERVER，现在用ORACLE很不顺手，感觉手上资料太少，遇到问题不好查询。   以下记录一个小技巧：select obj#, dataobj#, owner#, name, namespace, subname, type#, ctime, mtime, stime, status, remoteowner, linkname, flags, oid$, spare1, s

    刚学ORACLE的时候，就先入为主地认为rownum是一种类似于SQLSERVER的TOP关键字一样的机制————起码咱们最常用的分页可以用这个搞定。    事实并非如此，学习的时候，“空”是很重要的，以前的经验往往是一种坏处。    SQLSERVER中，如果TOP关键字和ORDER BY关键字一起出现，是先ORDER BY 后再TOP。也就是说：取得最前面的几条记录是经过排序的。  

我们常常在ORACLE的存储过程中这样处理错误：DECLARE      v_ErrorNo number(10);     v_ErrorMsg varchar2(255);BEGIN     --Some SQL HereEXCEPTION    WHEN OTHERS THEN        v_ErrorNo := SQLCODE;        v_ErrorMsg := SQLERRM

  今天在.NET里面调用ORACLE的存储过程，始终显示一堆错误，大概的意思好像是编译错误！     为什么会这样呢？花了一上午时间，这个问题还是没解决。代码是这样地：string strSql = @"BEGIN    AddUser(aa, bb);END;";OracleCommand cmd = new OracleCommand(strSql, conn);cmd.Execut

今天想学习学习ORALCE里面如何创建分区表照着例子写了一个，果然觉得很爽。然后又写一个复合分区的脚本，在PL/SQL  Developer里面执行，通过！结果，在PL/SQL Developer里面查看刚刚创建的表，却没有任何关于分区的信息。难道脚本错了？难道ORACLE的这个版本不支持复合分区？想啊想啊，测试啊，测试啊…………最后发现原来复合分区已经成功创建了，但是PL/SQL Develop

俺今天要在ORACLE里面导入一些数据，都是用户名，文件大概是这个样子的：DataFile.txt:张三李四王五…………然后俺创建了一个只有UserName列的表：create table TEMP_USERNAME(  USERNAME VARCHAR2(40)) NOLOGGING;然后俺在数据文件前面加上几列：load datainfile *fields terminated by WRI

为了便于在C语言的代码中处理ORACLE的时间，于是在SELECT的时候直接把日期转换成1970年以来的秒数： SELECT (sysdate - to_date(1970-01-01, yyyy-mm-dd))*24*60*60 FROM dual结果发现这个时间比C语言中的time_t值少了8小时，因此得到正确的time_t值应该这样写：SELECT (sysdate - to_dat

    偶然一次查看旧系统的存储过程的代码时，发现赋值操作都是：       SELECT 1234 INTO v_Value FROM dual;   这样的语法。    我以前也是做SQL SERVER开发的，在SQL SERVER中我也常用：SELECT v_Value=1234这样的语法来赋值。估计写这些代码的人可能也有SQL SERVER的背景。    比起 v_Value := 123

小记：不明原因的解决了ORACLE慢的问题    近来发现ORACLE服务器超级慢，而且慢并不是由应用程序性能导致的，就连运行proc预编译程序都很慢，可见问题还是出在ORACLE服务器本身。   首先查看了一下ORACLE的主要内存参数：SELECT "NUM","NAME","TYPE","VALUE"/1024 AS "KB","ISDEFAULT","ISSES_MODIFIABL