Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
11.05.2006, 09:27
|
|||
|---|---|---|---|
|
|||
Sybase IQ работа с VIEW |
|||
|
#18+
Вопрос собственно в следующем: Сталкивался ли кто с сабджем? Возникла следующая проблема: При работе с объединяющей по UNION ALL VIEW время отработки запроса напрямую зависит от кол-ва таблиц в оной. Если все слить в одну таблицу, то скоррость значительно возрастает, но данный вариант не устраивает из-за того, что нужно отказаться от сегментации данных (в данном случае речь идет о журнале, нарезка по месяцам, сум.объем 300000000 записей). Проблема номер 2 возникает при попытке связать эту VIEW с другой таблицей (в моем случае GLOBAL TEMPORARY). Время обработки запроса стремится к бесконечности. На всех таблицах из VIEW по соответствующим полям имеются как HG индексы, так и DATE индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.05.2006, 09:56
|
|||
|---|---|---|---|
Sybase IQ работа с VIEW |
|||
|
#18+
Нужно смотреть планы запросов и там уже определять в обоих случаях, почему происходят такие вещи. Так же неплохо почитать документацию и провести серию тестов, чтобы понять как работает в IQ оптимизатор с конструкцией UNION ALL ... в ASA 9 к примеру оптимизатор при указании фильтра на представление/подзапрос с UNION ALL автоматически уведет его в сами запросы UNION, таким образом избежав полного сканирования всех таблиц в UNION ALL с последующим пост-фильтром, а в MSSQL 2000 этого не произойдет - вполне возможно IQ так же не умеет оптимизировать UNION. Если это так, то как вариант - никто не мешает сделать ХП, в которую передаются нужные параметры фильтрации, собирается SQL скрипт и выполняется через динамический SQL (если конечно IQ поддерживает конструкцию SELECT * FROM StoredProc() ). -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.05.2006, 20:57
|
|||
|---|---|---|---|
Sybase IQ работа с VIEW |
|||
|
#18+
Я думаю нарезать таблицы по месяцам в СУБД, которая специально предназначена для организации хранилищ данных -- особого смысла не имеет. Хотя конечно я не пробовал сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.05.2006, 09:49
|
|||
|---|---|---|---|
|
|||
Sybase IQ работа с VIEW |
|||
|
#18+
MasterZiv безусловно прав, разбиение большой таблицы на несколько меньших в IQ особого смысла не имеет. Для начала неплохо бы плучить план запроса для обоих случаев: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. и Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Еще можно почитать: Performance and Tuning Guide Optimizing queries that reference UNION ALL views All partitions in a UNION ALL view must have a complete set of indexes defined for optimization to work. Queries with DISTINCT will tend to run more slowly using a UNION ALL view than a base table. • Split group by over union all view • Pushdown join into union all view Should you need to adjust performance for queries that reference UNION ALL views, you may want to set the Join_Preference database option, which affects joins between UNION ALL views. For details of these options, see Chapter 5, “Database Options” in the Sybase IQ Reference Manual. Reference Manual JOIN_PREFERENCE option Function Controls the choice of algorithms when processing joins. Allowed values -7 to 7 Alphabetical list of options 80 Sybase IQ Scope DBA permissions are not required to set this option. Can be set temporary, for an individual connection, or for the PUBLIC group. Takes effect immediately. Default 0 Description For joins within a query, the IQ optimizer has a choice of several algorithms for processing the join. This option allows you to override the optimizer's costbased decision when choosing the algorithm to use. It does not override internal rules that determine whether an algorithm is legal within the query engine. If you set it to any non-zero value, it affects every join in a query; it cannot be used to selectively modify one join out of several in a query. This option is normally used for internal testing, and only experienced DBAs should use it. The following table describes the valid values for this option and their action. Table 2-13: JOIN_PREFERENCE values JOIN_SIMPLIFICATION_THRESHOLD option Function Controls the minimum number of tables being joined together before any join optimizer simplifications are applied. Allowed values Integer from 1 to 64 Value Action 0 Let the optimizer choose 1 Prefer sort/merge 2 Prefer nested loop 3 Prefer nested loop push-down 4 Prefer hash 5 Prefer hash push-down 6 Prefer prejoin 7 Prefer sort/merge push-down -1 Avoid sort/merge -2 Avoid nested loop -3 Avoid nested loop push-down -4 Avoid hash -5 Avoid hash push-down -6 Avoid prejoin -7 Avoid sort/merge push-down ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=55&tablet=1&tid=2012870]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
51ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 217ms |
| total: | 333ms |

| 0 / 0 |
