forum.clarionlife.net

Были случаи, когда через месяц непрерывной работы сервера ребутят его, а винда начинает свои кэши на диск писать. "Что-то завис, наверное". Фигак по рубильнику с питанием. Но тогда не только индексы могут порушиться, а целиком отдельные табоицы (файлы). С btrieve так не экспериментировал.

finsoftrz писал(а): 30 Январь 2020, 13:12 С btrieve так не экспериментировал.

Давным-давно в тридесятом банке, по требованию Заказчка я такое делал.
Ровно 100 раз вырубал питание сервера при активной работе с БД по сети с 10 рабочими станциями (да простит меня этот сервер).
Было 2 сбоя, один убрали REBUILD, второй перезагрузкой списка через текст BUTIL.
Результат был признан отличным и мы получили и освоили тот заказ …

А у меня сейчас есть клиент, у которого весьма часто падает база tps и с трудом чинится, tpsfix по нехватке памяти вываливается. Файл размером около 400 мб. Работа исключительно локально

Возможно, антивирус. И, судя по всему, старый компьютер. Я начал напрягаться с переключателем на btrieve, когда рабочая и архивная части таблицы стали за гиг каждая. Но работало и с гиговой базой без сбоев, человек 10 в терминальных сессиях и еще человек 30-40 периодически через ip драйвер через интернет. По практике, желательно все же tps юзать в пределах 500мб. Я большие таблицы делаю на 2 физических файла, рабочий и архивный, с тем расчетом, чтобы основной объем данных постепенно оседал в архиве, который только на чтение. Большие таблицы затратно обслуживать в случае каких-то проблем. Такой подход и для tps, и для btrieve хорош.

RaFaeL писал(а): 31 Январь 2020, 18:02 у которого весьма часто падает база tps и с трудом чинится

Здесь определяющим является не размер TPS файла, а кол-во и размер ключей.
В линейном TPS файле - нечему падать, а вот если есть "большие" ключи, да по строкам … то вполне.

Сегодня столкнулся с таким глюком при работе с btrieve. Стандартно файлы базы данных открываются в многопользовательском доступе 42h с последующим bind(record), и тут все в порядке. Если пытаемся открывать с монопольном доступе 12h, то на таблицах с memo полями вываливается ошибка "невозможно открыть файл, так как не найдено memo". Причем не на всех, и зависит от порядка открытия файлов. По моему, тоже самое происходит и при открытии в режиме 42h без последующего bind(record).

Наткнулся на одной старой системной процедуре. Обычно монопольно ничего не открываю, захват делаю другими способами. Переставил на стандартное открытие, проблема ушла.

Clarion6, Win7 32, pervasiveSQL 10.

По поводу сбоев индексов в btrieve. Выяснилось, что админ втихаря запустил на сервере антивирус. Поставили каталог с базой данных в исключения, похоже, проблема ушла.

finsoftrz писал(а): 04 Февраль 2020, 11:26 Выяснилось, что админ втихаря запустил на сервере антивирус

Если бы это произошло, лет так 85 назад, то представляю заголовок в "Рязанской правде":
ОРГАНАМИ РАСКРЫТ ЗАГОВОР СИСАДМИНОВ-ВРЕДИТЕЛЕЙ, ПО НОЧАМ ЗАПУСКАВШИХ ВРАЖЕСКИЙ АНТИВИРУС …

У них там жесть была. Сервак ломанули по рдп и зашифровали. База осталась почти целиком жива, так как файлы были открыты в программе. Это еще на tps было. После этого регулярно что-то приделывают в плане безопасности. Админ не очень опытный, учится одновременно.

finsoftrz писал(а): 04 Февраль 2020, 12:49 База осталась почти целиком жива, так как файлы были открыты в программе.

Таки я Вам больше сейчас расскажу …
У меня есть клиент, который постоянно (видимо) кидает сотрудников и те при увольнении пытаются сделать
какую-нибудь гадость, например полностью удалить БД на сервере. Поэтому в его программе есть специальный
режим запуска на сервере, где открывается окошко со всеми списками БД, что бы файлы нельзя было бы грохнуть по сети …

Аналогично, обычно всегда запущена программа под администратором, в ней открыт список всех файлов. У крупных клиентов.

Точнее не так. Есть специальная обработка открыть/закрыть все таблицы/прогреть кэш. Под админом она запускается и висит в режиме, когда все таблицы открыты.

Что только не придумывают, лишь бы не SQL
Сколько клиентов ни обращались по поводу разных вирусных шифрований, базу ни у кого еще не получилось зашифровать. Да и грохнуть при уходе тоже

RaFaeL писал(а): 04 Февраль 2020, 13:37 Что только не придумывают, лишь бы не SQL

То же самое. Почитайте sql.ru. Держат коннект, чтобы базу не грохнули. У нашего заказчика админ форматнул диск с БД Файербёрд, работающей в боевом режиме. Заодно и бэкапы туда же. Не со зла, конечно. Учился, видимо.

RaFaeL писал(а): 04 Февраль 2020, 13:37 Что только не придумывают, лишь бы не SQL
Сколько клиентов ни обращались по поводу разных вирусных шифрований, базу ни у кого еще не получилось зашифровать. Да и грохнуть при уходе тоже

У нас тоже пока не было. Дело не в sql, там тоже данные в файлах лежат. Порой так лежат, что просто офигеть можно (это я про postgreSQL). Держать постоянно запущенную под админом копию программы - это стандартная практика. Если пользователей много и все серьезно. Помимо защиты файлов базы данных, у нас еще всякие операции по расписанию выполняются (не надо запускать отдельный шедулер), а также обрабатываются запросы на отчеты от удаленных пользователей, работающих через интернет без терминального режима.