VS调试程序提示：检测到ContextSwitchDeadlock

小白用Visual Studio调试程序时，等了大概1分钟，突然提示：检测到ContextSwitchDeadlock，Google后，有人建议要调整Managed Debugging Assistants的设置，可我的程序只增加了一点内容，用于调用Oracle中的Procedure啊，跟Managed Debugging Assistants没关系吧？

回去到Oracle客户端程序看，居然是刚刚用SELECT …… FOR UPDATE更新相关表数据，用于调试Procedure，忘了commit，导致锁表了。

所以才DeadLock。 😅

Oracle 11g 使用 UTL_MAIL 包实现Procedure发送邮件

想要通过Oracle的Procedure发送邮件，参考了这篇文章， 但是到了给非 SYS 用户赋权的时候就出错了。

具体出错是在以下这个命令时：

grant execute on dbms_network_acl_admin to al1

--上述命令中的al1是作者举例的，请替换成自己的Oracle用户。

原因是dbms_network_acl_admin这个对象根本不存在。

遇到的错误提示是：ORA-24248: XMLDB extensible security not installed，通过以下SQL语句也能确认。

Tiptop 4gl中如何调用Oracle存储过程

最近想用Tiptop程序直接调用Oracle的存储过程，从网上查资料发现了识途老驴的博客，测试后发现并不奏效，可能是版本不同吧，无法考证。

于是又查看了Genero的官方文档，曰：

To execute the stored procedure, you must include the procedure in an anonymous PL/SQL block with BEGIN and END keywords.

于是将4gl代码改造如下，即可执行。

     BEGIN WORK
    #PREPARE id1 FROM "CALL .pro_F001(?,?)"    #识途老驴的方法
     PREPARE id1 FROM "begin pro_F001(?,?); end;" #官方方法
     EXECUTE id1 USING l_str1 IN, l_str2 OUT   #传入所需参数
     PREPARE id2 FROM "begin pro_F002(); end;" #无需参数者
     EXECUTE id2
     COMMIT WORK

如果有参数同时具备传入/传出的参数，则为INOUT。

查询Oracle锁表和清除锁定

查询（用system或sys用户）

SELECT l.session_id sid, s.serial#, l.locked_mode,l.oracle_username,l.os_user_name,s.machine, s.terminal, o.object_name, s.logon_time
FROM v$locked_object l, all_objects o, v$session s
WHERE l.object_id = o.object_id
AND l.session_id = s.sid
ORDER BY sid, s.serial# ;

清除（将上面查询到的内容替换sid和serial#）

ALTER system KILL session 'sid,serial#';

揪出Oracle用户被锁的原因

最近Oracle的system用户总是被锁定，因为profiles设定了密码错误超过10次即被锁。

通过以下SQL语句找到了被锁的时间和电脑名称：

SELECT username, os_username, userhost, timestamp, returncode 

 FROM sys.dba_audit_session 

WHERE returncode != 0 

  AND timestamp > sysdate - 30; 

 又通过以下语句找到了更详细的时间：

SELECT os_username,userhost,comment_text,extended_timestamp,os_process,dbid 

  FROM dba_audit_trail

 WHERE USERNAME = 'SYSTEM'

   AND RETURNCODE=1017

   AND timestamp > sysdate - 30;

发现尝试登录的时间非常有规律，去被锁的电脑看，原来是一个脚本中把system的密码写死了，后来system密码改了，而脚本没改，所以……

在不重装的情况下清空Windchill系统中的CAD资料(Wiping the Windchill data without reinstalling)

公司去年上了PTC公司的PLM/PDM系统：Windchill，但因为研发人员对产品的规范有分歧，多次开会后，最后决定清空所有已上传的资料，包括产品库和存储库里的所有资料。

这说起来容易，做起来难啊，可苦了这帮IT兄弟了，谁叫咱是“挨踢人猿”呢……

Windchill系统里通过Creo上传的资料，一旦被其他产品引用，或进行了升级，想要删除是非常困难的，各种关联、约束都来了，大系统的好处就在这里。没办法，技术出身的，前台没法删，只能从数据库后台想办法了。

从Google查了很多资料，但提供这种思路的几乎没有，而且基本上是英文的，都来自PTC社区，最后终于有点线索了。只要清楚了Oracle的表结构，删除资料自然不是难事。废话少说，直接上干货：

清空所有以EPM开头的表，这些表存储了CAD文档及其关联关系；
清空WTPART表，这里存储了所有PART的信息；
清空BASELINEMEMBER表， 这里存储了所有BaseLine的信息。

上述表都是在PDMLINK11这个Users下的。 清空表之前最好做个备份，当然也要停止Apache的httpd服务，避免用户还在操作系统。

后台处理完后，开启httpd服务并登录Windchill，在右上角的“搜索”框旁点击小三角，选择“高级搜索“，关键字录入“*.*”，“类型”和“上下文”都选择“所有”，然后搜索，即可找到所有待删除的文件，全选再从“操作”里找到“删除”就能搞定了。

如果你在删除过程中遇到问题，欢迎留言与我讨论。

ORA-00257问题解决

今天登录Tiptop ERP测试环境时，出现错误“ ORA-00257: archiver error. Connect internal only, until freed”，通过以下方法手动释放归档空间后已OK，做个记录。

> rman target / 

RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';  ---删除7天前的所有归档日志

RMAN> CROSSCHECK ARCHIVELOG ALL;

RMAN> DELETE EXPIRED ARCHIVELOG ALL;

原文：https://blog.csdn.net/wenshuangzhu/article/details/44059809 

关闭归档功能的方法：https://blog.csdn.net/JohnnySun2015/article/details/74196786

定期删除归档脚本：https://blog.csdn.net/liqfyiyi/article/details/7017238 或 http://www.zhoudl.com/linux/1006.htm

Oracle事务中的DDL语句

最近一直都在跟Tiptop ERP战斗，User发现了一个严重的问题，采购订单自动发送邮件给厂商时，只有15个项次，但我们自己查询时居然是19项，用impdp把当天的数据翻出来看，也没发现问题。

只能去追查程序了，原来是因为sapmt540.4gl中有个函数t540_pmn25()，它的作用是检查请购单项次并将请购单项次的备注(pmo_file)写入采购单的备注(pmo_file)，读写pmo_file采用了操作临时表x来完成。其处理方法本身没问题，但该函数又被函数t540_b()调用，而对于临时表x的DDL操作（此处是DROP TABLE）会使TRANSACTION失效，不再锁定pmm_file，从而导致User A还在编辑采购订单的单身，User B就已把该采购订单审核甚至发出了。

解决办法：读写pmo_file的部分，改为FOREACH请购单项次的pmo_file资料，重新对pmo01/pmo02/pmo03赋值后，再INSERT到采购单项次的pmo_file。

终极原因：Oracle的DDL不是事务性的，运行DDL语句将隐式地提交该会话的任何打开的事务。

用impdp恢复expdp备份的某个表到另一Schema

有人把资料维护错了，后来偷偷改了，又不承认😠，逼得我去把备份的资料恢复出来，给她难堪……

因为是expdp备份的，对应的恢复就用impdp啦。

简单介绍下环境：Tiptop ERP的Oracle数据库，在Linux下运行，要从正式Schema（al1）的备份恢复到测试的Schema（ostest），只需恢复ima_file这个表。

直接上指令了：

impdp directory=EXPDP_DIR dumpfile=full_20180929.dmp logfile=imp_ostest_ima_20180930.log schemas=ostest include=table:\"in \'ima_file\'\"

没成功，错误提示：

ORA-31655: no data or metadata objects selected for job

原来是因为没有指明来源的Schema，调整指令为：

impdp directory="EXPDP_DIR" dumpfile=full_20180929.dmp logfile=imp_ostest_ima_20180930.log remap_schema=al1:ostest tables=al1.ima_file table_exists_action=replace

这样就OK了，如果没有加table_exists_action=replace，而目标Schema中已存在这个表，则会出现错误：

ORA-39151: Table "OSTEST"."IMA_FILE" exists. All dependent metadata and data will be skipped due to table_exists_action of skip

参考资料：OracleOnLinux

CR报表错误：certid驗證失敗 無法開啟報表

今天在Toptest应User需求调整CR报表对应程序后，做测试，程序调用IE浏览器显示报表时，出现错误提示：

certid驗證失敗 無法開啟報表

原来是因为最近把Oracle数据库迁移到了另一台Server，只在AP端改了数据库连接设定，CR服务器的却忘记了。

去Net Manager或直接修改tnsnames.ora文件即可搞定。

Oracle 默认用户密码的由来

接触过Oracle数据库的朋友可能多少会好奇，为什么Oracle的初始用户和密码是scott和tiger，其由来为何？

Oracle大牛Tony Jambu曾权威解释说：

Scott是Oracle的前身Software Development Laboratories的第4位职员，他是Oracle V1到V3的联合设计师和联合架构师，其全名为Scott Bruce。而tiger是他的宠物猫的名字。

参考信息： Burleson Consulting

初探Oracle的审计功能

早上有Tiptop的User反馈，凭证抛转还原时，提示表被锁，于是打开p_zta准备解锁，但输了几次Oracle的system和sys密码，都提示不正确。还以为是上月发生信息安全事件后，新改的管理员密码被我记错了，再跟Keepass核对，发现密码没问题。

于是用相同的密码从sqlplus尝试，提示：“ORA-28000: the account is locked”，居然是system帐户被锁定了。查资料发现：

可能是由于错误的密码输入次数超出了profile中failed_login_attempts 次数的限制而被锁定。

 通过如下SQL语句可以查看用户状态和被锁定时间：

SELECT username,account_status,lock_date FROM dba_users;

那就先解锁再说吧，语句如下：

alter user system account unlock; 

 处理完User的问题继续来追查system帐号被锁的原因。首先以sys的身份看Oracle是否已开启审计功能，过程及结果如下：

上图中，audit trial的值为DB，说明审计功能已开启，audit_file_dest的value是审计文件存储的位置。遂以OS的oracle用户身份查看审计文件，可令人失望的是，这里只记录了sys用户登录的审计结果，但我的问题是system用户因连续10次输入密码错误被锁定了。值得提一下的是，在这个审计文件中，STATUS的值为0表示正常登录，1017为登录失败。

又查了资料，原来普通的帐户登录，没有相应的os审计文件，但是被添加到了表SYS.AUD$，这下终于揪出原因了(是某个没有数据库管理员权限的同事在反复试system的密码)。我用的相关SQL语句如下：

SELECT userid, userhost, terminal, clientid,ntimestamp#,comment$text
FROM aud$
WHERE returncode=1017 AND userid='SYSTEM'
ORDER BY 5;

参考资料： 乐沙弥的世界