Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Весьма занимает судьба некоторых фич, которые, как я помню, когда-то обещали: * Индексы по выражениям * CREATE OR REPLACE * Сортировка по указанному в выражению COLLATE * LEO! (возможно, забыл что-то ещё). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2006, 09:20 |
|
||
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Хочу длинные имена для всего ;-(. Я стараюсь использовать схемы именования если таблица - tablename, то индекс tablename_field_field триггер перед удалением tablename_bi последовательность tablename_seq но в нынешней ситуации это не работает. Кто-нибудь видел LEO? Чтобы после нескольких прогонов запрос ускорился, и чтобы это было связано не с состоянием буферного пула, а сменой плана (накапливание статистики)? Или чтобы план менялся прямо во время исполнения (в этом узле ожидалось столько, на самом деле получилось по-другому, поэтому мы меняем план), и это можно было продиагностировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 23:25 |
|
||
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Как насчёт аналога переменных пакетов Oracle (чтобы облегчить миграцию с Oracle)? MTK пытается эмулировать через temporary tables, коряво, некрасиво, и не вполне соответствует (те переменные находятся вне транзакционного контекста)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 23:28 |
|
||
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaХочу длинные имена для всего ;-(. Я стараюсь использовать схемы именования если таблица - tablename, то индекс tablename_field_field триггер перед удалением tablename_bi последовательность tablename_seq но в нынешней ситуации это не работает. Кто-нибудь видел LEO? Чтобы после нескольких прогонов запрос ускорился, и чтобы это было связано не с состоянием буферного пула, а сменой плана (накапливание статистики)? Или чтобы план менялся прямо во время исполнения (в этом узле ожидалось столько, на самом деле получилось по-другому, поэтому мы меняем план), и это можно было продиагностировать. Слушай, мне кажется что это связано с количеством процессоров на системе и опцией Automatic profile updates (AUTO_PROF_UPD) = OFF . Я читал что если > 1 процессора то эта фича не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:08 |
|
||
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Длинные имена для всего будут. Глобальные переменные наверное будут, если не перенесут на 2007 год. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:19 |
|
||
|
Viper без XML
|
|||
|---|---|---|---|
|
#18+
Ну вот... http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.rn.doc/doc/c0023227.htm Constraint name 18 Unqualified user-defined type, user-defined function, user-defined method, buffer pool, table space, database partition group, trigger, index, or index specification name 18 Прочего упомянутого мной, как я понимаю, тоже нет. Посмотрим на судьбу другого моего предсказания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2006, 14:16 |
|
||
|
|
start [/forum/topic.php?fid=43&fpage=134&tid=1605417]: |
0ms |
get settings: |
22ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 241ms |
| total: | 380ms |
| 0 / 0 |
