win_64位平台报ora-12531
配置256g内存的机器，监听时连得上时连不上，然后查看监听日志，报
TNS-12531: TNS:cannot allocate memory，也不是次次都报，重复连个几次，就这样了；
查下MOS说明：
 | Windows: Oracle Net or Connections Via the Listener Fail with TNS-12531 On Windows 64-bit Platform (文档 ID 1384337.1) |
CAUSE
This can be caused by an inadequate setting for Desktop Heap Size. Even if this is a 64-bit OS with high amount of memory, there is still a limitation that generates this error.
Of course, it can also be caused when the memory is actually low. Check the resource consumption at the time of this problem. If there is no apparent memory shortage,
the solution documented here may resolve the issue.
SOLUTION
Check and edit the Desktop Heap size located here in the registry:
Launch regedt32 and go to:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\
In the right pane, click on Windows and pull down Edit then select Modify.
You should see a string that resembles this in its entirety:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sx***v,4 ProfileControl=Off MaxRequestThreads=16
Focus on this section:
Windows SharedSection=1024,20480,768
The third argument is the maximum amount of heap memory allocated to non interactive desktops.
Increase this third value and check when the TNS error disappears. There is no optimum value. It
varies on each MS Windows server.
说明一下：
第三个 SharedSection 值 (512) 是为"非交互式"窗口站与相关联的每个桌面桌面堆的大小。如果不存在此值为非交互式窗口站桌面堆的大小将与为交互式窗口站 （第二个 SharedSection 值） 指定的大小相同。
检查了一下这个值，为2048已经调大，如果加大，确实能缓解这个问题，但此时连接的会话并不多，才73个，那么问题明显不在这；是谁把这非交互式堆栈耗完了呢，看下了进程数，全为conhost&cmd.exe进程，也就是这玩意用完了；
简单暴力点，直接：taskkill /im:conhost.exe /f，没有再报错了；
官方也明确说了，这是个BUG
| Bug 14324057 - Windows: "%%i was unexpected at this time" when cluvfy executes (文档 ID 14324057.8) |
在11.2.0.3.10中修复；
验证方法：
C:\Users\oradba>%ORACLE_HOME%\bin\cluvfy comp nodecon -n all
临时解决办法是杀了就好了,如果做进程分析，可以考虑用windbg做下，
首先导入SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
open一个dmp文件，
windbg常用命令：
| 命令 | 说明 |
| .loadby sos clr | 加载调试扩展（.NET4.0以下使用mscorwks） |
| !threadpool or !tp | 显示有关托管线程池的信息 |
| ~* e!clrstack | 显示所有线程的堆栈 |
| ~* e!pe | 显示发生在所有线程上的最后的异常 |
| !runaway | 显示线程耗费的CPU时间 |
| !syncblk | 查看程序阻塞 |
| .logopen | 记录调试日志 |
| vertarget | 查看系统运行时间 |
| !peb | 查看完整的进程启动的命令行参数，加载的DLL及环境变量等 |
| !dml_proc | 查看进程Id及进程全路径名称 |
| .cls | 清屏 |
| q | 退出当前调试 |
| !analyze -v | 详细显示当前异常信息 |
| ~0s | 切换到指定线程(中间的数字表示线程号) |
| !clrstack | 查看线程的调用堆栈,仅提供托管代码的堆栈跟踪 参数 -p 显示托管方法的参数值 |
| !printexception 或 !pe | 显示当前活动线程上的最后一个异常 |
| !dumpstackobjects 或 !dso | 显示在当前堆栈的边界内找到的所有托管对象 |
| !dumpobj 或者 !do | 显示对象信息，指定任何有效的对象地址，就能查看该对象的内容 |
| !dumparray 或者!da | 显示数组信息 |
| !gcroot -nostacks | 显示对象内存引用；-nostacks 选项将搜索限制为垃圾回收器句柄和 Freachable对象 |
| !dumpheap –stat | 查看堆中的所有对象信息，包括类型信息，个数，大小等 |
| !dumpheap -mt | 查看指定类型的对象及大小，可以指定最小、大值 |
| !eeheap -gc | -loader | 查看托管对象和程序结构在内存中占用情况 |
| !address -summary | 查看进程的内存分布情况，包括非托管内存 |
| .foreach (myobj{!dumpheap -mt 008f4104-short}) {!do ${myobj}} | 输出多个对象信息，该命令会对于堆中所有类型为008f4104的对象，依次调用!do命令 |
下载WinDGG:http://msdn.microsoft.com/en-us/windows/hardware/hh852365
64bit:http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools_amd64/dbg_amd64.msi
32bit:http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi