Оптимизация апгрейда больших баз

[gl00mie]

Цитата:

Сообщение от Link

Похоже что на MSSQL все выглядит гораздо лучше, без оптимизаций. Постсинхронизация проходит за 6 часов

Это, видимо, без фиговой тучи скриптов обновления базы 3.0 -> 4.0.

Цитата:

Сообщение от Link

правда на 2008 сервере под VMWare съедает всю доступную память - 15 ГБ.

Настройкой СУБД занимался не я, так что тут вряд ли чем помогу. На оракловом сервере, про который я писал, что он ушел в своп, памяти было 48 Гб

Цитата:

Сообщение от Link

Пробовал экспортировать в сиквел процесс синхронизации, как указанно в мануале, это может дать улучшение производительности при параллельном запуске на нескольких клиентах.

В моем случае ощутимо ускориться удалось еще за счет того, что пакетный сервер был настроен на гораздо большее число потоков, нежели штатные 8: не все, конечно, но часть скриптов очень хорошо распараллеливается, а основная нагрузка все равно приходится на СУБД, поэтому при настройке имеет смысл ориентироваться на число ядер сервера БД, а не AOS.

Цитата:

Сообщение от Link

Интересно, вы данные через кубы проверяли. У меня простой джоб все в ексель выкладывает. В чем было преимущество делать через кубы?

В транзакционных таблицах - десятки миллионов записей, Excel подавится. К тому же отделом отчетности, который "ворочает кубы", были заранее написаны соотв. скрипты, и было бы глупо отказываться от удачной возможности переложить на них часть работы по выверке данных

Цитата:

Сообщение от Link

А мультисайт сразу активировали?

Нет, не сразу. Вообще, первый где-то месяц-полтора было не до мультисайта