当我们用SPAM或者SAINT打patch的时候，如果出错了，而此时OCS无法Reset。这时候可以采用以下两种方式处理

1.se37执行函数OCS_RESET_QUEUE就行Reset。若还不行，还可以用里面的Force的参数。此参数需要谨慎使用。

Resetting an OCS package queue with the "Force"  mode is very dangerous and should only be done in special situations and only if it was recommended or requested by the SAP support. Solving problems or error situations, which arise because of an unauthorized reset of an OCS package queue, is not covered by the standard SAP support. Such problems will then be handled by remote consulting which is not free of charge

2.其实Patch也是通过request的方式import到系统的，若方式1失效，还可以采用此方法

a.删除表pat03中patch 字段与该补丁对应的记录。

b.清空pat01、pat10的内容。

c.tp showbuffer查看此补丁对应的请求号，tp delfrombuffer 删除对应的request。命令为：

tp SHOWBUFFER DEV pf=/usr/sap/trans/bin/TP_DOMAIN_DEV.PFL

tp delfrombuffer SAPKIBIFQ2 DEV pf=/usr/sap/trans/bin/TP_DOMAIN_DEV.PFL

SAPKIBIFQ02为request号码，DEV为SID

最残忍的是下面这种情况：

3.而当我们打BASIS Patch的时候，若出错，很有可能前端GUI无法登录系统，或者很多Tcode报Dump错误。此时，可以采用tp r3i方式。。具体为

a. 仔细分析Slog, Alog,Ulog内容

b.TRBAT / TRJOB 记录为空

c.检查  tp showbuffer DE3 pf=/usr/sap/trans/bin/TP_DOMAIN_DEV.PFL tag=spam的输出内容

d.执行tp R3I ALL DE3 pf=/usr/sap/trans/bin/TP_DOMAIN_DEV.PFL -Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8  -Dsourcesystems= tag=SPAM"  

注意：R3i参数使用需谨慎，很容易导致系统的不一致，按照官方说法，一定是让SAP帮忙分析各类日志后，给出建议后再使用

以上三种方法，使用需谨慎。出现问题后，最好还是发OSS message,让专业人士远程上来帮忙解决。同时，打Patch前做好备份。