![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
You could consider forcing the index with the following syntx: This might remedy your current Production problem however it's a double-edged sword in that you are permanently (until you remove it) over-riding the optimizer, so if the fastest access plan were to change down the road, you wouldn't use it. I'd only consider this as a stop-gap measure until you can determine the underlying issue (hopefully others will speak to that). Here's a link to a Sybase whitepaper that discusses forceindex. http://www.sybase.com/detail?id=2602#538896 |
#3
| |||
| |||
|
|
Hiyas, We use ASE 11.5.1 on AIX 4.3. We've recently hit a problem (just started a month ago) with the wrong index being used on a production server greatly slowing down selects/updates. The strange thing is, copies of the database to test servers dont have this problem. Selects on the test server use a faster nonclustered index while the production server uses the clustered index which is much slower in the selects. We've had little luck with sybase support so far on this issue. Data distribution seems to be the only phrase uttered to us. Fragmentation is also a favourite. No meaningful answers on how we can check this or resolve it. Any ideas? Martin |
#4
| |||
| |||
|
|
While there have been a number of changes in the optimizer since 11.5.x, the basic information given by these commands is still the same (I believe there have been formatting changes, though). If that doesn't help you make sense of the output, post it here and you may get some good commentary on it. |
#5
| |||
| |||
|
|
While there have been a number of changes in the optimizer since 11.5.x, the basic information given by these commands is still the same (I believe there have been formatting changes, though). If that doesn't help you make sense of the output, post it here and you may get some good commentary on it. |
![]() |
| Thread Tools | |
| Display Modes | |
| |