Добрый день.
Я уже задавал вопрос в свяси с возникшей проблемой. Теперь - несколько иной вопрос.

На одном и том же ASA 8.0.3 лежат 2 базы. Одна - центральная, одна - региональная с одинаковой структурой.

В каждой из баз есть таблица DocLimits,
в которой есть поля LowLimit и HighLimit unsigned int NOT NULL

и индексы

В региональной базе в этой таблице 2млн. записей, в центральной - 16млн.

На региональной базе запрос
отрабатывает моментально по индексу:
Index Scan Scan L using index I_DocLimits_Hi

а
отрабатывает моментально по индексу:
Index Scan Scan L using index I_DocLimits_Lo

Т.е., понятно, в зависимости от условия выбирает более подходящий индекс (чтобы перебором обрабатывать меньшую часть таблицы).

На центральной базе же - полным перебором любой из этих запросов:
Table Scan Scan L sequentially

Результат запроса - 2 записи (на обеих базах).

я уже делал - не помогло.
Указывать план вручную - то же самое ( )

Вопрос: можно ли все-таки как-то заставить мега-оптимизатор использовать для построения плана хоть какой-нибудь индекс на большой таблице, т.е. в центральной базе?

Спасибо.

Dim2000
White Owl wrote:

> 4) Ну и в конце концов, запусти dbisql, запусти в нем свой запрос и
> ПОСМОТРИ ПЛАН запроса. Не надо гадать, как работает оптимизатор, надо
> просто посмотреть лог его работы.

Кстати, неплохо было бы заслать план сюда.
Posted via ActualForum NNTP Server 1.4

Это?

Table Scan Scan L sequentially

Table reference
Table name

DocLimits
Correlation name

L
Estimated rows

15185139
Estimated pages

1.1005e+005
Estimated pages in cache

102600
Estimated row size (bytes)

31
Page map

yes

Node Statistics

 
Estimates
 
Description
 
RowsReturned

1.5185e+007

Number of rows returned
PercentTotalCost

100

Run time as a percent of total query time
RunTime

92.988

Time to compute the results
CPUTime

37.963

Amount of CPU time required
DiskReadTime

55.026

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk
DiskRead

7451

Disk reads
DiskWrite

0

Disk writes

Subtree Statistics

 
Estimates
 
Description
 
RowsReturned

1.5185e+007

Number of rows returned
PercentTotalCost

100

Run time as a percent of total query time
RunTime

92.988

Time to compute the results
CPUTime

37.963

Amount of CPU time required
DiskReadTime

55.026

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk
DiskRead

7451

Disk reads
DiskWrite

0

Disk writes

Predicate
expr( L.LowLimit ) <= 35651891 : 37.712% Statistics
expr( L.HighLimit ) >= 35651896 : 61.545% Statistics

White Owl1) В ASA 8 нельзя задать принудительный индекс. Эта возможность появилась только в ASA 9.0.1
2) Правильный синтаксис задания принудительного индекса: ... from sometable WITH (INDEX(index_name))
3) Не стоит задавать индекс принудительно, это верный путь снизить производительность. Если оптимайзер считает что полный скан будет эффективней - значит он действительно будет эффективней. С исключениями я ни разу не встречался.

В моем случае выборка должна идти в 99% случаев по "концу" значений HighLimit, т.е. должен использоваться этот индекс. Я считаю, что это оптимально.

А он НИКОГДА его не использует! (на "большой" таблице)

Dim2000
White Owl wrote:

> 4) Ну и в конце концов, запусти dbisql, запусти в нем свой запрос и
> ПОСМОТРИ ПЛАН запроса. Не надо гадать, как работает оптимизатор, надо
> просто посмотреть лог его работы.

Кстати, неплохо было бы заслать план сюда.
Posted via ActualForum NNTP Server 1.4

По кнопке "View Plan" выдает еще такое:

SELECT
select * from DocLimits L WHERE L.LowLimit <= 35651891 AND L.HighLimit >= 35651896

Node Statistics

 
Estimates
 
Description
 
RowsReturned

3.5956e+006

Number of rows returned
PercentTotalCost

0

Run time as a percent of total query time
RunTime

0

Time to compute the results
CPUTime

0

Amount of CPU time required
DiskReadTime

0

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk

Subtree Statistics

 
Estimates
 
Description
 
RowsReturned

3.5956e+006

Number of rows returned
PercentTotalCost

100

Run time as a percent of total query time
RunTime

92.988

Time to compute the results
CPUTime

37.963

Amount of CPU time required
DiskReadTime

55.026

Time to perform reads from disk
DiskWriteTime

0

Time to perform writes to disk
DiskRead

16643

Disk reads
DiskWrite

0

Disk writes

Optimizer statistics

 
Value
 
Description
 
Costed subplans

1

The number of different enumeration strategies considered by the optimizer
Estimated cache pages

64260

Estimated cache pages available for this statement
CurrentCacheSize

524288

Current cache size in kilobytes
Isolation_level

0


Optimization_goal

All-rows


Optimization_level

9


ProductVersion

8.0.3 (5444)

Product version
User_estimates

Override-magic



Select list
L.DocLimitId

int
L.DocId

int
L.LowLimit

unsigned int
L.HighLimit

unsigned int
L.SalePrice

double

Options

 
Value
 
Description
 
Alias

talons0

Mounted database name
Ansi_blanks

Off


Ansi_integer_overflow

Off


Ansi_update_constraints

Cursors


Ansinull

On


BlankPadding

ON

Blank padding
BlobArenas

ON

Blob extension pages are stored separately from table pages
Blocking

On


Capabilities

13FFFDD

Database capability bits
CaseSensitive

OFF

Case sensitivity
CharSet

cp1251

Character Set
ClusteredIndexes

ON

Clustered indexes
CompressedBTrees

ON

Compressed B-Tree indexes are supported
Compression

OFF

Compression enabled
Conversion_error

On


Date_format

YYYY-MM-DD


Date_order

YMD


DBFileFragments

55

Database file fragments
DefaultCollation

1251CYR

Default Collation
Divide_by_zero_error

On


Encryption

None

Encryption type
Extended_join_syntax

On


File

D:\SQLData\Sybase\talons0.db

Database file
FileVersion

41

Database file version number
FreePageBitMaps

ON

Free database pages managed via bitmaps
HistogramHashFix

OFF

Fixed histogram hash implementation
Histograms

ON

Optimizer statistics maintained as histograms
IndexStatistics

OFF

Index Statistics
Language

us_english


MachineName

MAINKV

Name of the machine
MainHeapBytes

686776

Main heap bytes in cache
Max_plans_cached

20


MaxCacheSize

524288

Maximum cache size in kilobytes
Update_statistics

On


MinCacheSize

524288

Minimum cache size in kilobytes
Name

MAINKV


NumProcessorsAvail

4

Number of processors on server
PageSize

4096

Database page size
PeakCacheSize

524288

Peak cache size in kilobytes
Platform

Windows2003

Operating system platform
PlatformVer

Windows 2003 Build 3790

Operating system platform version
Precision

30


Prefetch

On


ProcessorArchitecture

X86

Processor architecture
ReadOnly

OFF

Database read-only mode
Row_counts

Off


Scale

6


SeparateCheckpointLog

ON

Checkpoint log maintained at end of system dbspace
SeparateForeignKeys

ON

Primary and foreign key indexes are stored separately
String_rtruncation

Off


StringHistogramsFix

ON

Fixed string histograms implementation
TableBitMaps

ON

Table bit maps supported
TempFileName

C:\WINDOWS\TEMP\asat0001.tmp

Database temporary file name
Time_format

HH:NN:SS.SSS


Timestamp_format

YYYY-MM-DD HH:NN:SS.SSS


Userid

DBA

User ID
VariableHashSize

ON

Hash length may be specified for BTree indexes

White Owl1) В ASA 8 нельзя задать принудительный индекс. Эта возможность появилась только в ASA 9.0.1
2) Правильный синтаксис задания принудительного индекса: ... from sometable WITH (INDEX(index_name))
3) Не стоит задавать индекс принудительно, это верный путь снизить производительность. Если оптимайзер считает что полный скан будет эффективней - значит он действительно будет эффективней. С исключениями я ни разу не встречался.

Или вот еще пример:
использует индекс по дате, как надо:
Index Scan Scan T using index ind_Talons_DatAzs_Status_Region_Fuel

А если так:
Уже нет!!!
Table Scan Scan T sequentially

Это что, тоже оптимально? Не встречали Вы, говорите? Ну, а я встречал... Может быть, хоть вам от осознания этого факта легче станет... Мне не становится...

White Owl YuRockЭто что, тоже оптимально?Да, скорее всего это оптимально. Индекс для работы тоже надо подгрузить с диска. Если сам индекс сильно фрагментирован, то оптимизатор может его забраковать именно из-за фрагментированости. Быстрее будет делать последовательное чтение всей таблицы с диска и нагрузить процессор, чем разгрузить процессор и нагрузить харддрайв беспорядочным чтением секторов.
Сильно хочешь индекс? Сделай свой любий индекс кластерным и дефрагментируй таблицу. Смотри команды CREATE CLUSTERED INDEX и REORGANIZE TABLE.

Поставь рядышком с ASA8 ASA9, загрузи в девятку копию своей базы и поиграйся с принудительным заданием индекса, смотри планы - увидишь на что тратится время.

Буду пробовать. Спасибо.

White Owl1) В ASA 8 нельзя задать принудительный индекс. Эта возможность появилась только в ASA 9.0.1
2) Правильный синтаксис задания принудительного индекса: ... from sometable WITH (INDEX(index_name))

Огромное спасибо. Поставил девятку, указал план запроса - и все взлетело!
Проблема закрыта.

Александр Гoлдун
Не переживай, еще откроется . Когда начнет тормозить из-за несоответствия индекса параметрам выборки. Посмотрел бы лучше index consultant. Попробуй сделать составной индекс, причем по одному полю ASC, по другому DESC. Послушай добрых людей: оптимизатор не так глуп, как тебе может показаться с поверхностного взгляда.
Такой индекс и был изначально, но он не использовался НИКОГДА, и я удалил его - сделал 2 на 2 поля. Сейчас я его вернул - без указания плана он по прежнему не используется, и запрос выполняется несколько минут. С Указанием плана - несколько миллисекунд.

Так что может оптимизатор и не так глуп, но уж точно не безупречен.