关于plsql 部分表查询不出来的问题

popowin

环境 linux +rac
连接工具plsql 8.0.1

在连接数据库之后,执行select * from v$session 一直处于查询状态,出不来结果
在sqlplus 下执行正常.这是为啥

PS:部分表(用户创建的表)是这种情况,但也有一部分是正常.

附件为10046 trace

[ 本帖最后由 popowin 于 2012-1-4 17:43 编辑 ]

Maclean Liu(刘相兵

plsql 是指PL/SQL Developer?

"在连接数据库之后,执行select * from v$session 一直处于查询状态,出不来结果"

请对PL/SQL Developer的session 做一个10046 or sql trace 并上传结果

Maclean Liu(刘相兵

ODM Data

1. /oracle/admin/racdb/udump/racdb2_ora_9402.trc
   
2. Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
   
3. With the Partitioning, Real Application Clusters, OLAP, Data Mining
   
4. and Real Application Testing options
   
5. ORACLE_HOME = /oracle/ora10g
   
6. System name:    Linux
   
7. Node name:    oracle-2
   
8. Release:    2.6.18-194.el5
   
9. Version:    #1 SMP Tue Mar 16 21:52:39 EDT 2010
   
10. Machine:    x86_64
    
11. Instance name: racdb2
    
12. Redo thread mounted by this instance: 2
    
13. Oracle process number: 56
    
14. Unix process pid: 9402, image: oracle@oracle-2
    
15. 
    
16. *** ACTION NAME:(Command Window - New) 2012-01-04 17:40:15.176
    
17. *** MODULE NAME:(PL/SQL Developer) 2012-01-04 17:40:15.176
    
18. *** SERVICE NAME:(racdb) 2012-01-04 17:40:15.176
    
19. *** SESSION ID:(1053.2913) 2012-01-04 17:40:15.176
    
20. WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599624196111
    
21. WAIT #1: nam='SQL*Net message from client' ela= 14278 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599624210695
    
22. =====================
    
23. PARSING IN CURSOR #2 len=61 dep=0 uid=63 oct=47 lid=63 tim=1294599624210792 hv=356401299 ad='59bee200'
    
24. begin :id := sys.dbms_transaction.local_transaction_id; end;
    
25. END OF STMT
    
26. PARSE #2:c=0,e=22,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1294599624210788
    
27. BINDS #2:
    
28. kkscoacd
    
29. Bind#0
    
30.   oacdty=01 mxl=2000(2000) mxlc=00 mal=00 scl=00 pre=00
    
31.   oacflg=01 fl2=1000000 frm=01 csi=852 siz=2000 off=0
    
32.   kxsbbbfp=2b87021f5d58  bln=2000  avl=00  flg=05
    
33. WAIT #2: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599624210996
    
34. EXEC #2:c=0,e=152,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1294599624211024
    
35. *** 2012-01-04 17:40:27.639
    
36. WAIT #2: nam='SQL*Net message from client' ela= 12155349 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636366428
    
37. =====================
    
38. PARSING IN CURSOR #1 len=21 dep=0 uid=63 oct=3 lid=63 tim=1294599636367721 hv=2564406738 ad='59bef4c8'
    
39. select 'x' from dual
    
40. END OF STMT
    
41. PARSE #1:c=1000,e=1116,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1294599636367715
    
42. BINDS #1:
    
43. EXEC #1:c=1000,e=71,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1294599636367864
    
44. WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636367898
    
45. WAIT #1: nam='SQL*Net message from client' ela= 633 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636368583
    
46. WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636368633
    
47. FETCH #1:c=0,e=35,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1294599636368657
    
48. WAIT #1: nam='SQL*Net message from client' ela= 3347 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636372074
    
49. STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='FAST DUAL  (cr=0 pr=0 pw=0 time=3 us)'
    
50. =====================
    
51. PARSING IN CURSOR #2 len=61 dep=0 uid=63 oct=47 lid=63 tim=1294599636372247 hv=356401299 ad='59bee200'
    
52. begin :id := sys.dbms_transaction.local_transaction_id; end;
    
53. END OF STMT
    
54. PARSE #2:c=0,e=25,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1294599636372243
    
55. BINDS #2:
    
56. kkscoacd
    
57. Bind#0
    
58.   oacdty=01 mxl=2000(2000) mxlc=00 mal=00 scl=00 pre=00
    
59.   oacflg=01 fl2=1000000 frm=01 csi=852 siz=2000 off=0
    
60.   kxsbbbfp=2b87021f5d58  bln=2000  avl=00  flg=05
    
61. WAIT #2: nam='SQL*Net message to client' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636372460
    
62. EXEC #2:c=0,e=175,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=1294599636372493
    
63. WAIT #2: nam='SQL*Net message from client' ela= 617 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636373160
    
64. =====================
    
65. PARSING IN CURSOR #2 len=37 dep=1 uid=0 oct=3 lid=0 tim=1294599636374899 hv=1398610540 ad='5af5c758'
    
66. select text from view$ where rowid=:1
    
67. END OF STMT
    
68. PARSE #2:c=1000,e=998,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1294599636374895
    
69. BINDS #2:
    
70. kkscoacd
    
71. Bind#0
    
72.   oacdty=11 mxl=16(16) mxlc=00 mal=00 scl=00 pre=00
    
73.   oacflg=18 fl2=0001 frm=00 csi=00 siz=16 off=0
    
74.   kxsbbbfp=2b87021f6290  bln=16  avl=16  flg=05
    
75.   value=000001CC.000C.0001
    
76. EXEC #2:c=2000,e=2021,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1294599636377019
    
77. FETCH #2:c=0,e=44,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=1294599636377104
    
78. STAT #2 id=1 cnt=1 pid=0 pos=1 obj=63 op='TABLE ACCESS BY USER ROWID VIEW$ (cr=1 pr=0 pw=0 time=28 us)'
    
79. =====================
    
80. PARSING IN CURSOR #1 len=25 dep=0 uid=63 oct=3 lid=63 tim=1294599636388424 hv=3206370776 ad='58566068'
    
81. select * from v$session
    
82. END OF STMT
    
83. PARSE #1:c=15997,e=15178,p=0,cr=2,cu=0,mis=1,r=0,dep=0,og=1,tim=1294599636388420
    
84. BINDS #1:
    
85. EXEC #1:c=0,e=45,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1294599636388545
    
86. WAIT #1: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=1294599636388635
    
87. WAIT #1: nam='SQL*Net more data to client' ela= 24 driver id=1413697536 #bytes=2001 p3=0 obj#=-1 tim=1294599636388750
    
88. WAIT #1: nam='SQL*Net more data to client' ela= 11 driver id=1413697536 #bytes=2005 p3=0 obj#=-1 tim=1294599636388847

复制代码

wait event  "SQL*Net more data to client"



related bug :

1. Bug 9087501: SELECT FROM V$SESSION AND SOME OTHER DICTIONARY VIEWS HANG FROM A REMOTE CLIENT      
   
2. 
   
3. Show Bug Attributes Bug Attributes
   
4. Type     B - Defect     Fixed in Product Version     -
   
5. Severity     2 - Severe Loss of Service     Product Version     10.2.0.4
   
6. Status     92 - Closed, Not a Bug     Platform     226 - Linux x86-64
   
7. Created     04-Nov-2009     Platform Version     RED HAT ENTERPRISE LINUX 5
   
8. Updated     11-Dec-2009     Base Bug     -
   
9. Database Version     10.2.0.4         
   
10. Affects Platforms     Generic         
    
11. Product Source     Oracle         
    
12. 
    
13. Show Related Products Related Products
    
14. Line     Oracle Database Products     Family     Oracle Database
    
15. Area     Net Services     Product     115 - Oracle Net Services
    
16. 
    
17. Hdr: 9087501 10.2.0.4 NET 10.2.0.4 PRODID-115 PORTID-226
    
18. Abstract: SELECT FROM V$SESSION AND SOME OTHER DICTIONARY VIEWS HANG FROM A REMOTE CLIENT
    
19. 
    
20. *** 11/04/09 02:45 pm ***
    
21. TAR:
    
22. ----
    
23. SR:2-5813605    (Previous 7711612.992)
    
24. 
    
25. PROBLEM:
    
26. --------
    
27. select * from v$session hang from a remote client connected through listener.
    
28. But same SQL runs ok with a local connection.
    
29. 
    
30. systemstate dump shows the session is waiting on client. So there might be
    
31. some problem with sql*net. However if turn on sql*net server trace, the
    
32. problem is gone.
    
33. 
    
34. DIAGNOSTIC ANALYSIS:
    
35. --------------------
    
36. checked sql*net trace and find many entries like:
    
37. 
    
38. nioqrc: exit  
    
39. nsmore2recv: entry  
    
40. nsmore2recv: testing for MOREDATA from transport  
    
41. sntpoltsts: fd 14 need 11 readiness event,wait
    
42. 
    
43. Asked customer to try patch 6734871 but it does not help.
    
44. 
    
45. WORKAROUND:
    
46. -----------
    
47. 
    
48. RELATED BUGS:
    
49. -------------
    
50. 
    
51. REPRODUCIBILITY:
    
52. ----------------
    
53. 
    
54. TEST CASE:
    
55. ----------
    
56. 
    
57. STACK TRACE:
    
58. ------------
    
59. 
    
60. SUPPORTING INFORMATION:
    
61. -----------------------
    
62. 
    
63. 24 HOUR CONTACT INFORMATION FOR P1 BUGS:
    
64. ----------------------------------------
    
65. 
    
66. DIAL-IN INFORMATION:
    
67. --------------------
    
68. 
    
69. IMPACT DATE:
    
70. ------------
    
71. 
    
72. 
    
73. new info: only windows client has this issue. A linux client at customer site
    
74. does not have the issue. For windows client, customer tested 9.2.0.1,
    
75. 10.2.0.1 and 10.2.0.4, all have problem.
    
76. 
    
77. 
    
78. Did you try sqlnet tracing on the windows client? Did problem reproduce?.
    
79. Did you enable sqlnet tracing at both client and server sides?
    
80. Could you please set event 10046 level 12 and reproduce the hang?
    
81. Does the hang happen if array size is changed to one in the sqplus session?
    
82. Please also get an errorstack dump when session hangs.
    
83. Thank you,
    
84. Agustin Amador.
    
85. 
    
86. 
    
87. Thank you for the update.
    
88. 
    
89. sqlnet client trace files shows that connections are using different naming
    
90. methods. On the hang case (client_8164.trc) it used TNSNAMES.
    
91. 
    
92. Could you please simplify the test case by:
    
93. 
    
94. 1) changing NAMES.DIRECTORY_PATH = (TNSNAMES, EZCONNECT) to
    
95. NAMES.DIRECTORY_PATH = (TNSNAMES)
    
96. 
    
97. so that TNSNAMES is always used
    
98. 
    
99. 2) Create a new tnsnames.ora file with just one basic connection string to
    
100. the server.
     
101. 
     
102. Reproduce the problem again and provide the same data:
     
103. 
     
104. a) sqlnet trace client (for both cases hang and no hang)
     
105. b) 10046 level 12 and errorstack level 3 dumps while session is hanging
     
106. 
     
107. 
     
108. Trace file client_6196_1.trc shows that client received the first package
     
109. from the server. Then it stopped waiting for more information from the
     
110. server.
     
111. 
     
112. ...
     
113. [12-NOV-2009 12:03:36:728] nsprecv: 631 bytes from transport
     
114. [12-NOV-2009 12:03:36:728] nsprecv: packet dump
     
115. [12-NOV-2009 12:03:36:728] nsprecv: 07 DB 00 00 06 00 00 00  |........|
     
116. [12-NOV-2009 12:03:36:728] nsprecv: 00 00 10 17 8D C9 C8 00  |........|
     
117. [12-NOV-2009 12:03:36:728] nsprecv: EA F8 1C 90 C5 DA E4 C3  |........|
     
118. ...
     
119. [12-NOV-2009 12:03:36:728] nsprecv: 00 00 22 00 01 80 00 00  |..".....|
     
120. [12-NOV-2009 12:03:36:728] nsprecv: 20 00 00 00 00 00 00 00  |........|
     
121. [12-NOV-2009 12:03:36:728] nsprecv: 00 00 00 00 00 00 00 00  |........|
     
122. [12-NOV-2009 12:03:36:728] nsprecv: 00 00 69                 |..i     |
     
123. [12-NOV-2009 12:03:36:728] nsprecv: normal exit
     
124. [12-NOV-2009 12:03:36:728] nsrdr: got NSPTDA packet
     
125. [12-NOV-2009 12:03:36:728] nsrdr: NSPTDA flags: 0x0
     
126. [12-NOV-2009 12:03:36:728] nsrdr: normal exit
     
127. [12-NOV-2009 12:03:36:728] nsdo: *what=1, *bl=2001
     
128. [12-NOV-2009 12:03:36:728] nsdo: nsctxrnk=0
     
129. [12-NOV-2009 12:03:36:728] nsdo: normal exit
     
130. [12-NOV-2009 12:03:36:728] nioqrc: exit
     
131. [12-NOV-2009 12:03:36:728] nioqrc: entry
     
132. [12-NOV-2009 12:03:36:728] nsdo: entry
     
133. [12-NOV-2009 12:03:36:728] nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0,
     
134. cflgs=0x3
     
135. [12-NOV-2009 12:03:36:728] nsdo: rank=64, nsctxrnk=0
     
136. [12-NOV-2009 12:03:36:728] nsdo: nsctx: state=8, flg=0x400d, mvd=0
     
137. [12-NOV-2009 12:03:36:728] nsdo: gtn=127, gtc=127, ptn=10, ptc=2011
     
138. [12-NOV-2009 12:03:36:728] nsdo: switching to application buffer
     
139. [12-NOV-2009 12:03:36:728] nsrdr: entry
     
140. [12-NOV-2009 12:03:36:728] nsrdr: recving a packet
     
141. [12-NOV-2009 12:03:36:728] nsprecv: entry
     
142. [12-NOV-2009 12:03:36:728] nsprecv: reading from transport...
     
143. [12-NOV-2009 12:03:36:728] nttrd: entry
     
144. ...
     
145. 
     
146. On the other hand, trace file mpint1_ora_25450.trc shows that server is
     
147. waiting for the client.
     
148. 
     
149. Call stack
     
150. ...
     
151. ksdxfdmp <- ksdxcb <- sspuser <- funlockfile <- read_nocancel
     
152. <- snttread <- nttrd <- nsprecv <- nsrdr <- nsdo
     
153. <- nsbrecv <- nioqrc <- opikndf2 <- opitsk <- opiino
     
154. <- opiodr <- opidrv <- sou2o <- opimai_real <- main
     
155. <- libc_start_main
     
156. ...
     
157.     ----------------------------------------
     
158.     SO: 0xdc169ed8, type: 4, owner: 0xdc0086e0, flag: INIT/-/-/0x00
     
159.     (session) sid: 421 trans: (nil), creator: 0xdc0086e0, flag: (41) USR/-
     
160. -/-/-/-/-/-
     
161.               DID: 0001-0025-0000070B, short-term DID: 0001-0025-0000070A
     
162.               txn branch: (nil)
     
163.               oct: 3, prv: 0, sql: 0x7581a1a0, psql: 0x65d983a0, user:
     
164. 5/SYSTEM
     
165.     O/S info: user: mng, term: INFRA-31, ospid: 1296:3904, machine:
     
166. FXALL\INFRA-31
     
167.               program: sqlplusw.exe
     
168.     application name: SQL*Plus, hash value=3669949024
     
169.     waiting for 'SQL*Net message from client' blocking sess=0x(nil) seq=135
     
170. wait_time=0 seconds since wait started=6
     
171.                 driver id=54435000, #bytes=1, =0
     
172.     Dumping Session Wait History
     
173.      for 'SQL*Net more data to client' count=1 wait_time=5
     
174.                 driver id=54435000, #bytes=7d0, =0
     
175.      for 'SQL*Net more data to client' count=1 wait_time=42
     
176.                 driver id=54435000, #bytes=7d4, =0
     
177.      for 'SQL*Net message to client' count=1 wait_time=3
     
178.                 driver id=54435000, #bytes=1, =0
     
179.      for 'row cache lock' count=1 wait_time=357
     
180.                 cache id=10, mode=0, request=3
     
181. ----
     
182. 
     
183. It seems client and server are going out of sync during the communication.
     
184. 
     
185. Questions:
     
186. 
     
187. - Is the client running windows vista? If yes please review note:444694.1   
     
188. 
     
189. - Does select sid from v$session run without problems (less data)?
     
190. 
     
191. - Please ask customer to set SDU=32768 and see if hang reproduces.
     
192. 
     
193. 
     
194. 
     
195. Thank you for the update.
     
196. 
     
197. Could you please try SDU parameter in the DESCRIPTION part. For example:
     
198. 
     
199. (DESCRIPTION =
     
200.    (SDU=32768)
     
201.    (ADDRESS_LIST =
     
202.      (ADDRESS = (PROTOCOL = TCP)(HOST = numpintdb01)(PORT = 1521))
     
203.    )
     
204.    (CONNECT_DATA =
     
205.      (INSTANCE_NAME = MPINT1)
     
206.    )
     
207. )
     
208. 
     
209. test again and provide the client's sqlnet trace.

复制代码

Maclean Liu(刘相兵

分析

1. 可能由 Bug 9087501引起 远程查询v$session 后hang住

2. 等待事件与bug描述 一致为 SQL*Net message to client

3.  PL/SQL 所在操作系统 是否是 windows vista?

若是 则参考Note ID 444694.1

1. Windows Vista Client Using SQL*Net Against a 10gR2 Database May Hang or Crash [ID 444694.1]
   
2. 
   
3. Applies to:
   
4. Oracle Net Services - Version: 10.2.0.3 to 10.2.0.3
   
5. 
   
6. 
   
7. Symptoms
   
8. 
   
9. A Windows Vista machine running Oracle client version  10.2.0.3 and connecting to the 10gR2 version of database may hang or crash when retrieving large amounts of data.  You may be able to connect and select from smaller tables without a problem.  Also, you might not experience this problem using the same client against a 10gR1 version of the database.
   
10. 
    
11. A server sqlnet trace may show the following stack:
    
12. 
    
13. [000001 02-JUL-2007 16:21:10:796] nioqper: error from nioqsn
    
14. [000001 02-JUL-2007 16:21:10:796] nioqper: ns main err code: 12571
    
15. [000001 02-JUL-2007 16:21:10:796] nioqper: ns (2) err code: 12560
    
16. [000001 02-JUL-2007 16:21:10:796] nioqper: nt main err code: 530
    
17. [000001 02-JUL-2007 16:21:10:796] nioqper: nt (2) err code: 54
    
18. [000001 02-JUL-2007 16:21:10:796] nioqper: nt OS err code: 0
    
19. 
    
20. A client sqlnet  trace will probably show a hang in a read like this:
    
21. 
    
22. (5888) [02-JUL-2007 13:57:25:036] nsprecv: reading from transport...
    
23. (5888) [02-JUL-2007 13:57:25:036] nttrd: entry
    
24. Changes
    
25. 
    
26. The installation of a Windows Vista OS or the upgrade of the database from pre-10gR2 to 10gR2 may trigger this problem where it did not exist before.
    
27. Cause
    
28. 
    
29. This problem is caused by the default setting for TCP Window Scaling in the Windows Vista operating system.  TCP Window scaling or "Receive Window Auto-Tuning" is enabled by default on Vista.  All other Windows operating systems have this feature set to disabled by default.
    
30. 
    
31. There are known issues with TCP connections of any kind and this feature.
    
32. Solution
    
33. Disable the TCP Window Scaling feature. See the following Microsoft Knowledge Base note:
    
34. 
    
35. http://support.microsoft.com/kb/934430
    
36. 
    
37. Instructions for disabling this feature are included in the note.

复制代码

在vista 上建议关闭TCP Window Scaling feature

4.
尝试在tnsname.ora 中设置SDU 可能可以解决该问题， 如

(DESCRIPTION =
   (SDU=32768)
   (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(HOST = numpintdb01)(PORT = 1521))
   )
   (CONNECT_DATA =
     (INSTANCE_NAME = MPINT1)
   )
)

popowin

谢谢ML了
PL/SQL 所在操作系统 是win2003.
加了SDU 也不成,仍然有这个问题
等周五晚上再试一下重启数据库吧

Maclean Liu(刘相兵

就其网络等待事件"SQL*Net message to client" 和 现有的Note来看 和 Server端的数据库实例关系不大，
可能是由于 客户端所在操作系统OS的网络设置引起的。

popowin

嗯,确定不是服务端的问题,应该是中间路由防火墙的问题.
跨网段连接会有部分表查询不出来问题,但同一个网段的却正常

popowin

找到问题了
是因为网关防火墙采用的是JUNIPER， 默认情况下Application Layer Gateway 设置了对SQL的控制造成的

1. High Virtual Circuit Wait Running SQL Through a Juniper Firewall [ID 1293202.1]
   
2.         修改时间 18-MAR-2011     类型 PROBLEM     状态 PUBLISHED         
   
3. In this Document
   
4.   Symptoms
   
5.   Changes
   
6.   Cause
   
7.   Solution
   
8.   References
   
9. 
   
10. Applies to:
    
11. 
    
12. Oracle Net Services - Version: 9.2.0.1 to 11.2.0.2 - Release: 9.2 to 11.2
    
13. Information in this document applies to any platform.
    
14. Symptoms
    
15. 
    
16. 
    
17. From DBControl, High 'virtual circuit wait' is seen on a 'SELECT' SQL.
    
18. 
    
19. 
    
20. From ASH Report in 65 minutes elapsed time:
    
21. Top User Events
    
22. 
    
23. 
    
24. Event                "Event Class"      % Event "Avg Active Sessions"
    
25. virtual circuit wait  Network           98.32    7.99
    
26. 
    
27. 
    
28. The database is experiencing low performance.
    
29. 
    
30. 
    
31. Changes
    
32. 
    
33. Firewall policy was implemented for security purposes.
    
34. 
    
35. Firewall Device: Juniper Firewall  SSG-520 with Firmware Version 6.2.0 R4.0 .
    
36. Cause
    
37. 
    
38. 
    
39. "SQL" feature in Juniper Firewall Application Layer Gateway (ALG) is causing the hang.  This feature is documented as a known issue in several other documents:
    
40. 
    
41. 
    
42. 
    
43. Document 1075432.1 - Archive Log Shipments Failing in Environment With Juniper Firewall (Doc ID Document 1068158.1 - Shared Server Connections Hung, Waiting on Virtual Circuit Status via Juniper Firewall
    
44. 
    
45. 
    
46. 
    
47. 
    
48. 
    
49. 
    
50. Solution
    
51. 
    
52. Disable "SQL" feature in Juniper Firewall.
    
53. 
    
54. Solution Step:
    
55. From the Admin Interface in Juniper Web Interface,
    
56. under Security -> Deep Inspection -> ALG (Application Layer Gateway),
    
57. 
    
58. Deselect the "SQL" feature (disable the feature).
    
59. 
    
60. The result is as in following graph:

复制代码

Maclean Liu(刘相兵

Very Good!

就是要有这样一个 troubleshooting 的过程！