9.1
Модераторы: m0p3e, edward_K, Модераторы
Re: 9.1
Я понял, конвертер не проверяет на уникальность таблицы с совпадающим XF$Title. По хорошему нужно доработать проверки в конвертере.
А для какой таблицы XF$Title повторилось, вы свою табличку добавляли?
А для какой таблицы XF$Title повторилось, вы свою табличку добавляли?
Re: 9.1
И всё-таки, не пойму: сейчас ещё раз прогоняю конвертацию в тестовом режиме - процесс идёт уже 3,5 часа и заканчиваться не собирается. Что у нас не так, как у людей?RAJAH писал(а):Почему-то у меня неделю в прошлом году конвертил... Может, обновили?pk писал(а):Конвертор Alter810-91 обрабатывает реальные БД час-три от силы
Re: 9.1
О, а я сижу соображаю, что не так, конвертация (тестирую на локале) рабочей базы шла 10 часов, база 9 ГБ.
Так это, получается, нормально?
Так это, получается, нормально?
Re: 9.1
Это быстро! Выше я уже писал, что конвертация шла неделю (!), база раз в 6-7 больше.Ольга писал(а):Так это, получается, нормально?
Re: 9.1
На время конвертации влияют многие факторы:
- Размер конвертируемых таблиц.
- Быстродействие дисковой подсистемы. Диски SAS (с большой частотой вращения) предпочтительнее, чем SATA или SCSI. Дает ускорение до 4-х раз. SSD-накопители обеспечивают выигрыш в несколько десятков раз по сравнению с НЖМД и ввиду сравнительно невысокой стоимости могут быть рекомендованы для использования в подобных процедурах. Но по поводу SSD есть информация, что если таблица большая (несколько Гб), то во время конвертации диск может "заглючить", а то и подвесить систему. Поэтому оптимально использовать SAS (что мы и сделали ).
- Для системы, работающей под Pervasive, это еще размер кэша Pervasive. Установка значения, превышающего объем самой большой таблицы, ускоряет ее докомпиляцию в несколько раз. На таблицах меньшего объема выигрыш может быть менее заметен. Поиграйте параметром Cache Allocation Size. Мы его выставляли больше, чем размер самой большой конвертируемой таблицы (благо размер памяти на серваке это сделать позволяет).
- Размер конвертируемых таблиц.
- Быстродействие дисковой подсистемы. Диски SAS (с большой частотой вращения) предпочтительнее, чем SATA или SCSI. Дает ускорение до 4-х раз. SSD-накопители обеспечивают выигрыш в несколько десятков раз по сравнению с НЖМД и ввиду сравнительно невысокой стоимости могут быть рекомендованы для использования в подобных процедурах. Но по поводу SSD есть информация, что если таблица большая (несколько Гб), то во время конвертации диск может "заглючить", а то и подвесить систему. Поэтому оптимально использовать SAS (что мы и сделали ).
- Для системы, работающей под Pervasive, это еще размер кэша Pervasive. Установка значения, превышающего объем самой большой таблицы, ускоряет ее докомпиляцию в несколько раз. На таблицах меньшего объема выигрыш может быть менее заметен. Поиграйте параметром Cache Allocation Size. Мы его выставляли больше, чем размер самой большой конвертируемой таблицы (благо размер памяти на серваке это сделать позволяет).
Re: 9.1
У нас MS SQL.
Re: 9.1
Благодарствую, ценная информация. У нас Первасив, но баз 9 штукAleksandr писал(а):На время конвертации влияют многие факторы:
Re: 9.1
У нас баз значительно больше. Есть такие у которых размер около 30 Гб (без журнала).Ольга писал(а):Благодарствую, ценная информация. У нас Первасив, но баз 9 штукAleksandr писал(а):На время конвертации влияют многие факторы:
Re: 9.1
Официально поддерживается работа Галактики 9.1 под PSQL v10.3. В настоящее время работа Галактики под PSQL v11.3 тестируется разработчиком.
Мы работаем под PSQL v11.
Мы работаем под PSQL v11.