Comments 23
Вы молодцы.
Я думаю, не стоит объяснять, что режим simple используется только в разработке, на тестовых серверах и его использование в продакшене — недопустимо. Вообще никак.
А вот тут я бы не был столько категоричным, все зависит от обстоятельств.
Еще вопросы, если не возражаете.
- А по другим клиентам настроили мониторинг бэкапов?
- Какие именно рекомендации по обслуживанию БД были выданы?
- Удалось ли выяснить, почему падала виртуалка?
- Что бы за гипервизор? Что использовалось в качестве хранилища?
Да, первым делом проверили бэкапы и настроили мониторинг для всех self-hosted клиентов. Для тех же, кого хостим сами — всё было настроено изначально.
А по другим клиентам настроили мониторинг бэкапов?
— Ответили выше.
Какие именно рекомендации по обслуживанию БД были выданы?
— Перевести модель восстановления БД в режим full, мониторить состояние бэкапов, выполнять бэкапы с проверкой CHECKSUM и проверять бэкапы после создания RESTORE VERIFYONLY. Также, рекомендовали регулярно проводить восстановление из бэкапов на специальном стенде.
Удалось ли выяснить, почему падала виртуалка?
— Нет, наверняка выяснить не удалось, т.к. доступа к хостовой машине и логам не было, но сложилось впечатление, что в поврежденных секторах диска были не только файлы бд, но и какие-то системные, что и приводило к крашу.
Что бы за гипервизор? Что использовалось в качестве хранилища?
— Это выяснить не удалось, т.к. между IT службой клиники и нашей командой был заказчик в качестве посредника, и не вся информация до нас доходила.
— Ответили выше.
Какие именно рекомендации по обслуживанию БД были выданы?
— Перевести модель восстановления БД в режим full, мониторить состояние бэкапов, выполнять бэкапы с проверкой CHECKSUM и проверять бэкапы после создания RESTORE VERIFYONLY. Также, рекомендовали регулярно проводить восстановление из бэкапов на специальном стенде.
Удалось ли выяснить, почему падала виртуалка?
— Нет, наверняка выяснить не удалось, т.к. доступа к хостовой машине и логам не было, но сложилось впечатление, что в поврежденных секторах диска были не только файлы бд, но и какие-то системные, что и приводило к крашу.
Что бы за гипервизор? Что использовалось в качестве хранилища?
— Это выяснить не удалось, т.к. между IT службой клиники и нашей командой был заказчик в качестве посредника, и не вся информация до нас доходила.
Где хранить файлы конечно тема спорная. Но в данном случае хранение в базе мне видится излишним: если аудио-записи и генерируемые документы (их вообще можно не хранить, а генерировать по запросу) хранились бы как отдельные файлы в файловой системе, то сама база была бы значительно меньше, как и вероятность сбоя (транзакции по обновлению информации по работам минимальны). Создание бэкапа базы было бы простым и быстрым.
А так по сути сами придумали проблему, сами решили.
P.S. Возможно для хранения в базе были какие весомые причины, напр. требования заказчиков.
А так по сути сами придумали проблему, сами решили.
P.S. Возможно для хранения в базе были какие весомые причины, напр. требования заказчиков.
Если хранить не в БД, будут дополнительные костыли. Но вообще есть такая вещь как FILESTREAM.
UFO just landed and posted this here
Всё верно, на это были требования. Сейчас в БД лежат только документы, аудио хранятся в файловой системе. Но тут скорее проблема не в этом, а промах в администрировании: если бы всё было настроено правильно, не важно какой был бы размер БД и что в ней хранилось.
Я так понял, что клиника данные пациентов в открытом виде хранит, без шифрования?
Ух. Если честно, я бы очень не хотел, чтобы аудио файл моих разговоров с врачом бесконтрольно вместе с его расшифровкой летал между кабинетом, клиникой и Вами. Я надеюсь, что данные обрабатываются максимально неперсонализированно, но вероятность проблем с конфиденциальностью сильно больше, чем если бы всего этого не было.
Зачем вообще хранятся историчные аудио, если уже есть их расшифровка? Производятся ли какие-то шаги, чтобы снизить возможный урон? Алгоритм разбора настолько тяжелый, что его совсем нереально запускать на АРМ врача?
Зачем вообще хранятся историчные аудио, если уже есть их расшифровка? Производятся ли какие-то шаги, чтобы снизить возможный урон? Алгоритм разбора настолько тяжелый, что его совсем нереально запускать на АРМ врача?
Старые аудио удаляются в соответствии в data retention policy.
Сложность расшифровки связана со спецификой и сложностью распознавания медицинской терминологии и для клиники экономически выгоднее отдать транскрибирование на аутсорс, чем делать это своими силами. Это позволяет экономить приличные суммы ежегодно.
Сложность расшифровки связана со спецификой и сложностью распознавания медицинской терминологии и для клиники экономически выгоднее отдать транскрибирование на аутсорс, чем делать это своими силами. Это позволяет экономить приличные суммы ежегодно.
Непонятно, почему сразу после выявления ошибок DBCC не скопировали файлы базы. При их копировании сразу бы обнаружили аппаратные проблемы. Пытаться чинить с помощью DBCC базу на поврежденном диске — прямой путь окончательно убить базу. Если нет места, купить в магазине 4тб диск и подключить его куда угодно…
В момент выявления ошибок не было мыслей куда-то копировать файлы, т.к. ещё не было догадок про аппаратные проблемы и мы даже предположить не могли, что могут отсутствовать бэкапы на лайв системе.
<ворчание mode=on>Привыкли уже все работать на виртуалках, отвыкли как ломаются базы при аппаратных проблемах дисков или памяти, или как безвозвратно бьется лог-файл при отключении питания (когда отключают сам бесперебойник), что база не работает уже ни в каком из режимов suspect.
Оставлю ссылку на всякий случай dba.stackexchange.com/a/29758
Оставлю ссылку на всякий случай dba.stackexchange.com/a/29758
Sign up to leave a comment.
Рождественская история