Когда пора уходить с Pervasive?

[empyros]

Работаем на Pervasive 9.5
БД 70 ГБ + журнал (50 ГБ)
Активных юзеров около 50 человек.
На быстродействии не сильно заметно, но ТП уже давно рекомендует.

Есть какие-нибудь критерии для перехода?
На сайте Pervasive - больше маркетинговая информация, а форумы англоязычные - мне не доступны...
Какие последствия могут быть, если продолжать работать на Pervasive?

[sth73]

Если все работает нормально, зачем переходить?
Имхо - любые действия в своей основе должны иметь объективные причины.
Переходить в стиле "на всякий случай" - есть ли в этом нужда?
Ну и не забываем про цену вопроса. Я имею в виду банально деньги.

[Den]

Работаем на Pervasive 9.5
БД 70 ГБ + журнал (50 ГБ)
....
Активных юзеров около 50 человек.
На быстродействии не сильно заметно....

А относительно чего Вы сравнивали быстродействие ? или это Ваши ,чисто внутренние, ощущения...

[empyros]

В том-то и дело, что не понятно, работает ли она "нормально", если что-то не работает (сейчас проблемы с журнализацией), ТП говорит - из-за Pervasive. Руководству нужны вещественные доказательства, а не просто слова.

Поэтому интересуют критерии, при каком объеме БД, числе пользователей (может какие-то другие показатели) надо отказаться от Pervasive.

По быстродействию - претензий нет, возможно на другой платформе оно было бы и в разы быстрее.
После перехода с 7.12 на 8.10 стала работать быстрее, поэтому не особо думали можно ли еще ускориться...

[Den]

Можно попробовать сконвертить БД Вашу в другую платформу и потестить критичные для Вас вещи на новой субд - будет с чем сравнить. Конвертер уж даст наверное техподдержка радь такого дела

[empyros]

Можно попробовать сконвертить БД Вашу в другую платформу и потестить критичные для Вас вещи на новой субд - будет с чем сравнить. Конвертер уж даст наверное техподдержка радь такого дела

Сконвертировать можно, а вот менять платформу только из-за повышения быстродействия... никто не будет... кризис все-таки, лучше долго, но дешево.
Убедить уйти от Pervasive возможно будет только в том случае, если Галактика на нем не сможет работать, а вот когда она не сможет работать - это вопрос...

[Начинающий путь]

Работаем на Pervasive 9.5
БД 70 ГБ + журнал (50 ГБ)
Активных юзеров около 50 человек.
На быстродействии не сильно заметно, но ТП уже давно рекомендует.


Есть какие-нибудь критерии для перехода?
На сайте Pervasive - больше маркетинговая информация, а форумы англоязычные - мне не доступны...
Какие последствия могут быть, если продолжать работать на Pervasive?

Внимательно читая пост у меня возникли следующие вопросы:

1. Список самых больших таблиц и размер их
2. Как и на каком железе располагается Г-ка и Pervasive
3. За сколько времени хранится журнал
4. Самые длинные по времени процедуры/действия в Г-ке

А ТП может рекомендовать переход на другие платформы, потому что Г-ка дороже на них, но админить Г-ку все же придется Вам.

[KATZ]

1) Журнал 50 ГБ - это слишком. Зачем столько? Практика показывает, что пользователи, напортачив, спохватываются довольно быстро, проходит не больше недели. Более старые журнальные записи требуются крайне редко. Мы у себя раз в месяц журнал заводим заново, старый, естественно, заархивировав и сохранив. Кроме того, здесь писали про встроенное в "Галактику" сохранение журнала, тоже может быть полезно.
2) БД 70 ГБ - это не предел, но и не мало. Попробуйте проанализировать, за какой срок вам реально надо хранить данные. Какими бы мощными ни были компьютеры и СУБД - всё равно БД нужно ограничивать. Раз в году можно старые данные обрезать и не держать их в рабочей БД, а базу перед обрезанием сохранить куда-нибудь в надежное место вместе с актуальной версией "Галактики". Скорее всего, она никогда не потребуется, но если вдруг что-нибудь - будет где взять.
3) Файлы с данными лучше перевести в последний поддерживаемый формат (т. е. если у вас Pervasive v9, то и файлы должны быть с этой версией, а не с 7 или 8).
4) То, что ТП рекомендует менять платформу - понятно. Если у вас 50 пользователей, то, грубо говоря, 50 раб. мест куплено, каждое в среднем, допустим, по 1'000 у. е., итого на 50'000. MSSQLно-оракульные версии дороже первазивных на 20%, т. е. 10'000 у. е. ваша ТП получит не прикладая рук, плюс за конвертацию на новую платформу, плюс увеличенное АО, плюс... Но нужно ли это вам? Если есть 10 тыс. баксов, потратьте их лучше на покупку 64-разрядного сервера с 20-30 ГБ ОЗУ, поставьте Pervasive v10 x64, и за счет увеличения кэша с max 2 ГБ на 32-разрядной архитектуре в 10-15 раз получите весьма ощутимый прирост в скорости.
5) Ну и касательно журнала еще один маленький совет. Если конфигурация дисков позволяет, то папку D_DICT можно разместить не вместе с БД, а на другом физическом диске / дисковом массиве (см. справку по параметру Database.SchemeAlias). При одновременной записи изменений в рабочие таблицы и в журнал обращение пойдет на разные физические диски, что должно дать выигрыш в скорости.

P. S. Все написанное выше - мое скромное ИМХО. Решать, понятное дело, вам.

[Masygreen]

При гигантской базе .. если вы не используете какое нибудь BI, а обходитесь только галактическими отчетами может стать критичным время формирования этого отчета( а то и невозможность его сформировать)
на платформе SQL,Ora можно в отчетах использовать прямой SQL - он довольно кривенький но все равно выигрыш по сравнению с первасиом порядки ...

[empyros]

Размер таблиц:
TTNDOC.DAT 6,0
SPSOPR.DAT 3,5
SPSTEP.DAT 2,5
SPSCHF.DAT 3,5
SPORDER.DAT 3,0
OBOROT.DAT 2,2
ATTRVAL.DAT 4,1
Остальные таблицы меньше 2 ГБ.

Все расположено на 1 сервере: БД, Галактика, ключ.
Работы по разводу планируются.
Журнал никогда не чистился
Сейчас при выключенной журнализации удалили все файлы JOURNAL.* (на форуме про это писали здесь), получили ошибку с кодом 11 (невозможно открыть файл), журнализация больше не запускается... собственно из-за этого вопрос и поднялся. Когда исправим (если исправим) - будет журнал за 1 месяц - достаточно.

Самые длинные процедуры - получение отчетов (реализация).

3) Файлы с данными лучше перевести в последний поддерживаемый формат (т. е. если у вас Pervasive v9, то и файлы должны быть с этой версией, а не с 7 или .

Это рековером? Изначально с 810 работаем на 9.5.

Про деньги и 64 разрядный сервер понятно...
Ну нет претензий к быстродействию, тут все устраивает...
А вот если администратору взять на себя ответственность и сказать, что лучше купить новый сервер и остаться на Pervasive, а через месяц все ляжет... докажи, что ты не лось, тебе ТП все уши прожужжало о смене платформы. С другой стороны купить MSSQL, найти администратора, увеличить себе абонентское... ну очень не маленькие деньги, при этом мнение ТП - здесь уже не поможет, они заинтересованные, где найти аргументы.
Если не рассматривать вопрос быстродействия, какие ошибки могут быть при дальнейшем использовании Pervasive? При определенном количестве пользователей и объеме БД, Галактика может тупо не запуститься или начать ломать таблицы из-за Pervasive ?

[Начинающий путь]

да ни такие и большие таблицы

Попробуйте перепаковать файлы rebuild (C:\PVSW\Bin\rbldgui.exe)


По поводу ошибки 11- одна из ошибок: Указанное имя файла не верно. Если используется Pervasive SQL V9, то следует учитывать его неспособность работать с русскими буквами в пути к файлам базы данных. Необходимо указать латинское название каталога с программой

Если таблицы нет, то Pervasive должен сам создать ее.

Pervasive (btrieve) достаточно давняя БД, поэтому тупо ломать таблицы не будет. Слом таблиц может наступить при нехватке свободного места на винте или произойдет сбой сервера по железу.

И еще, что MSSQL, что ORACLE гораздо больше требовательнее к железу, чем Pervasive - железяку все таки придется купить...

[KATZ]

Размер таблиц:
TTNDOC.DAT 6,0
. . .
ATTRVAL.DAT 4,1
Остальные таблицы меньше 2 ГБ.

А эти две почему такие большие? Кстати, попробуйте пару-тройку таблиц прогнать через RECOVER. Может, в них информации немного, а размер большой, т. к. Pervasive автоматически файлы не сжимает. Если после RECOVER-а размер уменьшится более чем на 10-15% - есть смысл сделать это для всех больших файлов.

Сейчас при выключенной журнализации удалили все файлы JOURNAL.*, получили ошибку с кодом 11 (невозможно открыть файл), журнализация больше не запускается... собственно из-за этого вопрос и поднялся. Когда исправим (если исправим) - будет журнал за 1 месяц - достаточно.

Удалять можно и при включенной журнализации, лишь бы в БД в этот момент никого не было. Если физического файла нет - при первом обращении к таблице "Галактика" или "Support" его должны создать и дальше продолжать с ним работать. Причину ошибки вам на месте удобнее искать. Может, каких-нибудь прав на объекты файловой системы не хватает, может, еще что... Заочно точный диагноз не поставить...

Это рековером?

Можно и им, но, как справедливо сказал Начинающий путь, удобнее утилитой Rebuild.

Ну нет претензий к быстродействию, тут все устраивает...

У вас на редкость покладистые пользователи...

А вот если администратору взять на себя ответственность и сказать, что лучше купить новый сервер и остаться на Pervasive, а через месяц все ляжет...
Если не рассматривать вопрос быстродействия, какие ошибки могут быть при дальнейшем использовании Pervasive? При определенном количестве пользователей и объеме БД, Галактика может тупо не запуститься или начать ломать таблицы из-за Pervasive ?

Ляжет из-за ограничений на размеры таблиц? Одномоментно не ляжет, тревожным симптомом здесь в первую очередь и будет быстродействие. Если оно начинает прогрессивно падать - пора задуматься об ответных шагах. А у вас оно всех устраивает... 50 пользователей и БД на 70 ГБ - для Pervasive далеко не предел.
Таблицы могут поломаться независимо от размера, здесь (ИМХО) качество серверного "железа" решающую роль играет. Тупо не запуститься "Галактика" тоже вроде не должна, только если разработчики прочитают тему и, захотев ускорить ваш переход на новую платформу, учтут ваши опасения при выпуске очередного патча

[lStep]

Ускорить Pervasive:
- Дефрагментация - вот, что хорошо ускорит и Минимум 30% свободы на диске.
- Raid 0+1
остальное не заметно.

RECOVER заметно скорости не даст. В Pervasive ВСЁ по индексам и быстро или без индекса и ооочень медленно.
Галактика пользует первое на 99%.

PervasiveSQL - это хороший Верный пёс. Он не предаст. Если он завоет, значит совсем не кормите. MS SQL и Oracle сдохнут у того, у кого завоет Pervasive. Я к тому, что им уход нужен. И по скорости: DSQL-то быстрее, а всё остальное? Вряд-ли. Всё по индексам написано, а это всем хорошо одинаково!

Причина перехоить на MS SQL - это сторонний конект к данным Галактики для отчетов, кубов и прочее.

[Dvar]

ИМХО, Pervasive недо-СУБД. В его патчах видели сколько они крашей закрывают? И ведь еще остаются))
Были примеры когда простой запрос типа
select column from table where ... валит Первасив насмерть.
SQL Server и Oracle себе такого не позволяют.
Нет никаких средств решения проблем с производительностью, сторонние коннекты та еще песня.
Средств бэкапа (встроенных) никаких.
Ломаются таблицы.
И т.д.
А еще он денег стоит за свою глюки...

Жаль Голактего на бесплатных не работает, а то типа СПО сделали, а СУБД-то платную нужно.