Member since
05-25-2017
5
Posts
1
Kudos Received
0
Solutions
06-22-2017
12:49 PM
Thanks for your reply. As you can tell, we have already used your option1 as we do a select * from the table. We are using hint already to avoid creating of covered index as the app team is doing select *. Any other suggestions?
... View more
06-20-2017
06:27 PM
Hi Josh, What level of logging is required? Thanks
... View more
06-20-2017
02:29 PM
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
Labels:
- Labels:
-
Apache Phoenix
05-25-2017
03:47 PM
1 Kudo
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
Labels:
- Labels:
-
Apache HBase
-
Apache Phoenix