hi all

Когда база содержит здоровенные таблицы, то восстановление индексов по ним занимает бОльшую часть времени. Периодически слышны стенания о том, как было бы хорошо, если бы рестор умел запускать несколько потоков (= числу процессоров на сервере ?) и в каждом из них ресторить индексы таблиц.
У мну это несколько раз тоже было актуальным, вот и решил сравнить два варианта построения индексов (на таблице с полем ID int, 10^9 строк):

var-1. Открытие двух isql-окон и одновременный (почти) запуск в них:


(т.е. ввожу в первом окне на выполнение, дальше быстрый Alt-Tab и ввод во втором окне)

var-2. Открытие одного окна и запуск в нём:

Перед тем, как замерять статистику, скрипт
был однократно выполнен, а затем индексы были тут же грохнуты - чтобы файл базы уже был расширен до необх. размера.
После этого было:
1) рестарт операционки и запуск var-1. Запись статистики и удаление созданных индексов.
2) снова рестарт операционки и запуск var-2 с записью статистики.

Ну так вот: иллюзия ускорения создания двух индексов при почти одновременном запуске соотв-щих DDL ушла как вода в песок.
А заодно снова появились вопросы по странным цифиркам в isql-статистике.

Нижеследующие данные получены на базе со страницей 16K, кешем буферов 65000, FW = OFF.
Физически на хосте 1 cpu-сокет и 4 ядра, для linux-виртуалки сконфигурировано 8 логических ядер.

Таблица- I. Статистика isql :Сценарий создания двух индексовКоннект, транзакцияВыполнявшийся стейтментisql: elapsed time, secisql: readsisql: wirtesisql: fetchesvar-1. Одновременный старт DDL в двух isqlATT_202, TRA_4061 of 1: create ascending index10305,767047042878428 4006201494 ATT_204, TRA_4081 of 1: create descending index10305,347046606878428 4005998506 var-2. Последовательный запуск двух DDL в одном isqlATT_209, TRA_4321 of 2: create ascending index4952,6942747374318502004769359ATT_209, TRA_4332 of 2: create descending index4985,4142747134465852004720252

Таблица- II . Статистика trace :Сценарий создания двух индексовКоннект, транзакцияВыполнявшийся стейтментtrace: elapsed time, mstrace: readstrace: wirtestrace: fetchestrace: marksvar-1. Одновременный старт DDL в двух isqlATT_202, TRA_4061 of 1: create ascending index103054923483818 4373 2005524571863664ATT_204, TRA_4081 of 1: create descending index103053103563216691322005469612893138var-2. Последовательный запуск двух DDL в одном isqlATT_209, TRA_4321 of 2: create ascending index49524604274729678032004769211863664ATT_209, TRA_4332 of 2: create descending index49852734274701677992004720125893138

Итого:
1) время создания индексов при попытке их "распараллелить" по двум сеансам оказывается больше (пусть и ненамного), чем время последовательного создания в одном коннекте двух индексов;
2) не понимаю совершенно, откудова взялось 4 млрд фетчей в статистике isql при "параллельном" варианте (см таблицу-1);
3) также не уловил юмора с числом записей = 4373 по статистике трейса (в этом же "параллельном" варианте, таблица-2);
4) откудова такое дикое несовпадение между значениями writes по трейсу и по isql ? 68 тыс против 432 тыс - разница почти в 6 раз, и это в лучшем случае! Как такое понимать ?

В аттаче - фрагменты трейса для соотв-щих COMMIT_TRAN.

PS.

dimitr1) тест бессмысленный, ибо так распараллеливать создание индексов никто в здравом уме не будеттогда как было бы правильно, имея в руках только штатный isql ?
dimitr2) 2 млрд + 2 млрд. В супере ISQL показывает дельту изменений в базе вообще, а не конкретным коннектом. Так что при параллельном выполнении они суммируются.Насколько сложно это исправить ? Ибо засада полная получается:



Получаем в окне_2 форменный бред: не накопительный, а какой-то "скачущий" результат
dimitr3) 64К страниц влезли в кеш, 68 - 64 = 4. Почему сброс кеша по коммиту сюда не попал, пока не ясно - либо баг, либо фоновый cache writer успел все сбросить.
4) трейс показывает только операции самого коннекта. Остальные writes относятся к cache writer-у и тут не видны.А по этому cache writer-у в трейс можно добавить статистику ? А то какой-то "теневой игрок" появился, про которого ничего нельзя выяснить...

afgmнужно кучу сил положитьА так ли велика куча сия ?

0) Выполнить рестор только данных таблицы, получить таким обр. точное значение числа строк в ней;
1) Брать индексы с 1-го по N-й, где N = число_cpu_ядер, найти в них самый длинный ключ. Умножить его длину (maxKey) на число записей в таблице и на какой-то там "повышающий коэффициент" для запаса (сколько доп. памяти требуется для сортировки и построения индекса ?).
2) Сравнить это число с имеющейся свободной памятью на машине (не с TempCacheLimit, а со всей свободной памятью!). Если оно больше, взять минимум из них и поделить на maxKey с отбрасыванием дробной части. Получим в итоге то число индексов (p), построение которых можно распараллелить.
3) Запустить 'p' потоков. Поскольку они в каждый интервал времени будут читать примерно одни и те же страницы, кеширование должно сыграть роль: страницы, нужные потоку-2, еще не будут вытеснены из кеша, т.к. поток-1 прочитал их "вот только что".
4) Брать далее индексы с (p+1)-го по (p+1+N)-й и повторить пункт "1)" - и так до тех пор, пока не будут построены все индексы для таблицы.

Ы ?

dimitrТаблоидтогда как было бы правильно, имея в руках только штатный isql ?
это невозможно средствами isqlОК, а если на java попробовать это всё сбацать, запустив два потока - так будет корректно ?
dimitrнет в АПИ средств получить эту информациюфигасе... спасибо, буду поиметь теперь в виду: никогда не юзать статистику isql в SS, если "рядом" еще что-то крутится.
dimitrстатистика CW тебе ничего не даст. Во-первых, это фоновый поток (общий для всех коннектов) и его активность к твоей транзакции никак не привязать. Во-вторых, он работает вне контекста транзакций и его счетчики можно вывести только при его завершении, сиречь отключении последнего юзера от базы.Печалько... Показ длительности записи кеша на диск мог бы многое прояснить. Ну да ладно.

Симонов Дениспри многопользовательской работе, нельзя никак оценить сколько фетчей сделал конкретный запрос (определить его эффективность)?Во-во... :(
...и как-то сам по себе SuperClassic вдруг вспомнился... ;-)

Симонов ДенисНет, так как каждый поток будет читать данные с диска. Внутри движка по идее их можно прочитать один раз, если я правильно понимаю.Какая-то порция данных таблицы, прочитанная full scan'ом, в кеше разве не удержатся ?