We have Phoenix 4.7 with HDP 2.5.3. Web application is connecting to Phoenix through ODBC driver. After checking web win server event log and it seems the problem is related to failures in Phoenix ODBC driver. The pattern we are seeing is this: 1.Error messages in windows application event log: Faulting application name: w3wp.exe, version: 8.5.9600.16384, time stamp: 0x5215df96 Faulting module name: PhoenixODBC_sb64.dll, version: 1.0.6.1008, time stamp: 0x58eeaca8 Exception code: 0xc00000fd Fault offset: 0x00000000002f1ed9 Faulting process id: 0x22bc Faulting application start time: 0x01d2e9b26e8ecebb Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: D:\opt\Hortonworks Phoenix ODBC Driver\lib\PhoenixODBC_sb64.dll Report Id: b0fb4ab4-55a5-11e7-80d1-005056975329 Faulting package full name: Faulting package-relative application ID: 2.Each error above is followed by two info messages Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: w3wp.exe P2: 8.5.9600.16384 P3: 5215df96 P4: PhoenixODBC_sb64.dll P5: 1.0.6.1008 P6: 58eeaca8 P7: c00000fd P8: 00000000002f1f05 P9: P10: Attached files: C:\Windows\Temp\WER3C42.tmp.appcompat.txt C:\Windows\Temp\WER3D5D.tmp.WERInternalMetadata.xml C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_1df2c73c944e598668e38249d3eeedc6292292f3_9e3fd63b_cab_003e3db8\memory.hdmp C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_1df2c73c944e598668e38249d3eeedc6292292f3_9e3fd63b_cab_003e3db8\triagedump.dmp These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_1df2c73c944e598668e38249d3eeedc6292292f3_9e3fd63b_cab_003e3db8 Analysis symbol: Rechecking for solution: 0 Report Id: e18e1aa2-5594-11e7-80d1-005056975329 Report Status: 4 Hashed bucket: 3.After five (5) consecutive crashes above, the IIS application pool is being disabled automatically with the following messages in the system event log: Application pool '*AppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool. 4.The message above is also being preceded by five (5) warnings: A process serving application pool '*AppPool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '3124'. The data field contains the error number. @Josh Elser, could you please suggest? ... View more

We have Phoenix 4.7 with HDP 2.5.3. Two questions came up when we worked on secondary indexes on phoenix tables: 1. With functional global secondary index, even though we are using index hint, the secondary index is not being used in the query execution plan. For example, create a functional index first: create index IDX_UPPER on S1.TABLE1 (UPPER(FIRST_NAME)); EXPLAIN SELECT /*+ INDEX(S1.TABLE1 IDX_UPPER) */ * FROM S1.TABLE1 WHERE UPPER(FIRST_NAME) = 'ABC'; Execution plan: CLIENT 10-CHUNK 0 ROWS 0 BYTES PARALLEL 10-WAY ROUND ROBIN FULL SCAN OVER S1.TABLE1 SERVER FILTER BY UPPER(FIRST_NAME) = 'ABC' SERVER 500 ROW LIMIT CLIENT 500 ROW LIMIT How can we make sure functional index is forced to use in the query? 2. If we have multiple secondary indexes, what is the correct syntax? We tried INDEX(<table_name> <index_name1> <index_name2>), the explain plan showed that only the first index index_name1 is being used. Is this the expected behaviour? ... View more