Hi all
We are running several vehicle searches in transaction VELO with TREX enabled. In most cases, TREX seems to correctly operate and the search is quicker than with TREX disabled, as expected.
However, in one scenario, the search with TREX enabled is significantly slower.
The criteria for this search is:
Velo Filter: Vehicle Status
Availability Data: IV
Production Date: 06.01.2014 (from and to)
We have traced the search and have seen the following SQL running:
SELECT
"MANDT", "VGUID", "VHCLE", "MATNR", "LIFNR", "CHARG", "EQUNR", "WERKS", "LGORT", "BWTAR",
"CUOBJ", "CUABA", "MMCTR", "MMSTA", "MMTSP", "SDCTR", "SDSTA", "SDTSP", "KUNNR", "ENDCU",
"VHVIN", "VHCEX", "AVAIL", "VBLTY", "LOCTN", "GPRICE", "GPRICECUKY", "CDTSP", "PSTSP", "PDTSP",
"ERNAM", "VHUSG", "CMPGN", "PCOUNT", "PCOUNT_U", "IMMATDATE", "VHSAR", "VHORD", "SHLVL",
"ARCHIVE_FLAG", "USED_VEHICLE"
FROM
"VLCVEHICLE"
WHERE
"MANDT"=:A0 AND "PDTSP" BETWEEN :A1 AND :A2 AND "VGUID" IN (:A3 ,:A4 ,:A5 ,:A6 ,:A7 ) AND "MATNR"
IN (:A8 ,:A9 ,:A10 ,:A11 ,:A12 ,:A13 ,:A14 ,:A15 ,:A16 ,:A17 ,:A18 ,:A19 ,:A20 ,:A21 ,:A22 ,:A23
,:A24 ,:A25 ,:A26 ,:A27 ,:A28 ,:A29 ,:A30 ,:A31 ,:A32 ,:A33 ,:A34 ,:A35 ,:A36 ,:A37 ,:A38 ,:A39
,:A40 ,:A41 ,:A42 ,:A43 ,:A44 ,:A45 ,:A46 ,:A47 ,:A48 ,:A49 ,:A50 ,:A51 ,:A52 ,:A53 ,:A54 ,:A55
,:A56 ,:A57 ,:A58 ,:A59 ,:A60 ,:A61 ,:A62 ,:A63 ,:A64 ,:A65 ,:A66 ,:A67 ,:A68 ,:A69 ,:A70 ,:A71
,:A72 ,:A73 ,:A74 ,:A75 ,:A76 ,:A77 ,:A78 ,:A79 ,:A80 ,:A81 ,:A82 ,:A83 ,:A84 ,:A85 ,:A86 ,:A87
,:A88 ,:A89 ,:A90 ,:A91 ,:A92 ,:A93 ,:A94 ,:A95 ,:A96 ,:A97 ,:A98 ,:A99 ,:A100 ,:A101 ,:A102
,:A103 ,:A104 ,:A105 ,:A106 ,:A107 ,:A108 ,:A109 ,:A110 ,:A111 ,:A112 ,:A113 ,:A114 ,:A115 ,:A116
,:A117 ,:A118 ,:A119 ,:A120 ,:A121 ,:A122 ,:A123 ,:A124 ,:A125 ,:A126 ,:A127 ,:A128 ,:A129 ,:A130
,:A131 ,:A132 ,:A133 ,:A134 ,:A135 ,:A136 ,:A137 ,:A138 ,:A139 ,:A140 ,:A141 ,:A142 ,:A143 ,:A144
,:A145 ,:A146 ,:A147 ,:A148 ,:A149 ,:A150 ,:A151 ,:A152 ,:A153 ,:A154 ,:A155 ,:A156 ,:A157 ,:A158
,:A159 ,:A160 ,:A161 ,:A162 ,:A163 ,:A164 ,:A165 ,:A166 ,:A167 ,:A168 ,:A169 ,:A170 ,:A171 ,:A172
,:A173 ,:A174 ,:A175 ,:A176 ,:A177 ,:A178 ,:A179 ,:A180 ,:A181 ,:A182 ,:A183 ,:A184 ,:A185 ,:A186
,:A187 ,:A188 ,:A189 ,:A190 ,:A191 ,:A192 ,:A193 ,:A194 ,:A195 ,:A196 ,:A197 ,:A198 ,:A199 ,:A200
,:A201 ,:A202 ,:A203 ,:A204 ,:A205 ,:A206 ,:A207 ,:A208 ,:A209 ,:A210 ,:A211 ,:A212 ,:A213 ,:A214
,:A215 ,:A216 ,:A217 ,:A218 ,:A219 ,:A220 ,:A221 ,:A222 ,:A223 ,:A224 ,:A225 ,:A226 ,:A227 ,:A228
,:A229 ,:A230 ,:A231 ,:A232 ,:A233 ,:A234 ,:A235 ,:A236 ,:A237 ,:A238 ,:A239 ,:A240 ,:A241 ,:A242
,:A243 ,:A244 ,:A245 ,:A246 ,:A247 ,:A248 ,:A249 ,:A250 ,:A251 ,:A252 ,:A253 ,:A254 ,:A255 ,:A256
,:A257 ,:A258 ,:A259 ,:A260 ,:A261 ,:A262 ,:A263 ,:A264 ,:A265 ,:A266 ,:A267 ,:A268 ,:A269 ,:A270
,:A271 ,:A272 ,:A273 ,:A274 ,:A275 ,:A276 ,:A277 ,:A278 ,:A279 ,:A280 ,:A281 ,:A282 ,:A283 ,:A284
,:A285 ,:A286 ,:A287 ,:A288 ,:A289 ,:A290 ,:A291 ,:A292 ,:A293 ,:A294 ,:A295 ,:A296 ,:A297 ,:A298
,:A299 ,:A300 ,:A301 ,:A302 ,:A303 ,:A304 ,:A305 ,:A306 ,:A307 ,:A308 ,:A309 ,:A310 ,:A311 ,:A312
,:A313 ,:A314 ,:A315 ,:A316 ,:A317 ,:A318 ,:A319 ,:A320 ,:A321 ,:A322 ,:A323 ,:A324 ,:A325 ,:A326
,:A327 ,:A328 ,:A329 ,:A330 ,:A331 ,:A332 ,:A333 ,:A334 ,:A335 ,:A336 ,:A337 ,:A338 ,:A339 ,:A340
,:A341 ,:A342 ,:A343 ,:A344 ,:A345 ,:A346 ,:A347 ,:A348 ,:A349 ,:A350 ,:A351 ,:A352 ,:A353 ,:A354
,:A355 ,:A356 ,:A357 ,:A358 ,:A359 ,:A360 ,:A361 ,:A362 ,:A363 ,:A364 ,:A365 ,:A366 ,:A367 ,:A368
,:A369 ,:A370 ,:A371 ,:A372 ,:A373 ,:A374 ,:A375 ,:A376 ,:A377 ,:A378 ,:A379 ,:A380 ,:A381 ,:A382
,:A383 ,:A384 ,:A385 ,:A386 ,:A387 ,:A388 ,:A389 ,:A390 ,:A391 ,:A392 ,:A393 ,:A394 ,:A395 ,:A396
,:A397 ,:A398 ,:A399 ,:A400 ,:A401 ,:A402 ,:A403 ,:A404 ,:A405 ,:A406 ,:A407 )
The ABAP trace shows 'Select VLCVEHICLE' as taking 369 seconds from a gross time of 444 seconds. This is an exceptionally long time for a query that would appear to be efficient (at least, according to the SQL execution plan) - it is searching on VGUID which it has obtained via TREX (but why does it still query PDTSP? Surely if TREX has returned the relevant VGUIDs then it doesn't need this - could this be the cause of the performance issue?).
With TREX disabled, the SQL captured is like so:
SELECT "MANDT", "VGUID", "VHCLE", "MATNR", "LIFNR", "CHARG", "EQUNR", "WERKS", "LGORT", "BWTAR", "CUOBJ",
"CUABA", "MMCTR", "MMSTA", "MMTSP", "SDCTR", "SDSTA", "SDTSP", "KUNNR", "ENDCU", "VHVIN", "VHCEX", "AVAIL",
"VBLTY", "LOCTN", "GPRICE", "GPRICECUKY", "CDTSP", "PSTSP", "PDTSP", "ERNAM", "VHUSG", "CMPGN", "PCOUNT",
"PCOUNT_U", "IMMATDATE", "VHSAR", "VHORD", "SHLVL", "ARCHIVE_FLAG", "USED_VEHICLE" FROM "VLCVEHICLE" WHERE
"MANDT"=:A0 AND "AVAIL"=:A1 AND "PDTSP" BETWEEN :A2 AND :A3 AND "MATNR" IN (:A4 ,:A5 ,:A6 ,:A7 ,:A8 ,:A9 ,:A10
,:A11 ,:A12 ,:A13 ,:A14 ,:A15 ,:A16 ,:A17 ,:A18 ,:A19 ,:A20 ,:A21 ,:A22 ,:A23 ,:A24 ,:A25 ,:A26 ,:A27 ,:A28
,:A29 ,:A30 ,:A31 ,:A32 ,:A33 ,:A34 ,:A35 ,:A36 ,:A37 ,:A38 ,:A39 ,:A40 ,:A41 ,:A42 ,:A43 ,:A44 ,:A45 ,:A46
,:A47 ,:A48 ,:A49 ,:A50 ,:A51 ,:A52 ,:A53 ,:A54 ,:A55 ,:A56 ,:A57 ,:A58 ,:A59 ,:A60 ,:A61 ,:A62 ,:A63 ,:A64
,:A65 ,:A66 ,:A67 ,:A68 ,:A69 ,:A70 ,:A71 ,:A72 ,:A73 ,:A74 ,:A75 ,:A76 ,:A77 ,:A78 ,:A79 ,:A80 ,:A81 ,:A82
,:A83 ,:A84 ,:A85 ,:A86 ,:A87 ,:A88 ,:A89 ,:A90 ,:A91 ,:A92 ,:A93 ,:A94 ,:A95 ,:A96 ,:A97 ,:A98 ,:A99 ,:A100
,:A101 ,:A102 ,:A103 ,:A104 ,:A105 ,:A106 ,:A107 ,:A108 ,:A109 ,:A110 ,:A111 ,:A112 ,:A113 ,:A114 ,:A115 ,:A116
,:A117 ,:A118 ,:A119 ,:A120 ,:A121 ,:A122 ,:A123 ,:A124 ,:A125 ,:A126 ,:A127 ,:A128 ,:A129 ,:A130 ,:A131 ,:A132
,:A133 ,:A134 ,:A135 ,:A136 ,:A137 ,:A138 ,:A139 ,:A140 ,:A141 ,:A142 ,:A143 ,:A144 ,:A145 ,:A146 ,:A147 ,:A148
,:A149 ,:A150 ,:A151 ,:A152 ,:A153 ,:A154 ,:A155 ,:A156 ,:A157 ,:A158 ,:A159 ,:A160 ,:A161 ,:A162 ,:A163 ,:A164
,:A165 ,:A166 ,:A167 ,:A168 ,:A169 ,:A170 ,:A171 ,:A172 ,:A173 ,:A174 ,:A175 ,:A176 ,:A177 ,:A178 ,:A179 ,:A180
,:A181 ,:A182 ,:A183 ,:A184 ,:A185 ,:A186 ,:A187 ,:A188 ,:A189 ,:A190 ,:A191 ,:A192 ,:A193 ,:A194 ,:A195 ,:A196
,:A197 ,:A198 ,:A199 ,:A200 ,:A201 ,:A202 ,:A203 ,:A204 ,:A205 ,:A206 ,:A207 ,:A208 ,:A209 ,:A210 ,:A211 ,:A212
,:A213 ,:A214 ,:A215 ,:A216 ,:A217 ,:A218 ,:A219 ,:A220 ,:A221 ,:A222 ,:A223 ,:A224 ,:A225 ,:A226 ,:A227 ,:A228
,:A229 ,:A230 ,:A231 ,:A232 ,:A233 ,:A234 ,:A235 ,:A236 ,:A237 ,:A238 ,:A239 ,:A240 ,:A241 ,:A242 ,:A243 ,:A244
,:A245 ,:A246 ,:A247 ,:A248 ,:A249 ,:A250 ,:A251 ,:A252 ,:A253 ,:A254 ,:A255 ,:A256 ,:A257 ,:A258 ,:A259 ,:A260
,:A261 ,:A262 ,:A263 ,:A264 ,:A265 ,:A266 ,:A267 ,:A268 ,:A269 ,:A270 ,:A271 ,:A272 ,:A273 ,:A274 ,:A275 ,:A276
,:A277 ,:A278 ,:A279 ,:A280 ,:A281 ,:A282 ,:A283 ,:A284 ,:A285 ,:A286 ,:A287 ,:A288 ,:A289 ,:A290 ,:A291 ,:A292
,:A293 ,:A294 ,:A295 ,:A296 ,:A297 ,:A298 ,:A299 ,:A300 ,:A301 ,:A302 ,:A303 ,:A304 ,:A305 ,:A306 ,:A307 ,:A308
,:A309 ,:A310 ,:A311 ,:A312 ,:A313 ,:A314 ,:A315 ,:A316 ,:A317 ,:A318 ,:A319 ,:A320 ,:A321 ,:A322 ,:A323 ,:A324
,:A325 ,:A326 ,:A327 ,:A328 ,:A329 ,:A330 ,:A331 ,:A332 ,:A333 ,:A334 ,:A335 ,:A336 ,:A337 ,:A338 ,:A339 ,:A340
,:A341 ,:A342 ,:A343 ,:A344 ,:A345 ,:A346 ,:A347 ,:A348 ,:A349 ,:A350 ,:A351 ,:A352 ,:A353 ,:A354 ,:A355 ,:A356
,:A357 ,:A358 ,:A359 ,:A360 ,:A361 ,:A362 ,:A363 ,:A364 ,:A365 ,:A366 ,:A367 ,:A368 ,:A369 ,:A370 ,:A371 ,:A372
,:A373 ,:A374 ,:A375 ,:A376 ,:A377 ,:A378 ,:A379 ,:A380 ,:A381 ,:A382 ,:A383 ,:A384 ,:A385 ,:A386 ,:A387 ,:A388
,:A389 ,:A390 ,:A391 ,:A392 ,:A393 ,:A394 ,:A395 ,:A396 ,:A397 ,:A398 ,:A399 ,:A400
The SQL looks less efficient, as would be expected without TREX, but this is only taking 53 seconds to run whereas with TREX enabled it is taking over 7 minutes!
Please can you explain why this is?
The execution plan for the first query shows an estimated cost of only 2; the second shows around 5000 - however, I realised that you can't directly compare costs for different statements. But can anyone else see why the first query would take so much longer?
Thanks
Ross