VadimF,

Время, я так понимаю, московское?

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

И документации все меньше и меньше. Кажется, в текущей версии нет даже информации о структуре базы.

Alexey Maslov,

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

DirksDR,

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

Блок А.Н.,

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

DAiMor,

а еще есть такой способ. Сам бы не додумался, но ребята из СибЭКО попросили помочь. Удалили важные записи, нужно было восстановить. Нашли у журналов объектный интерфейс, просканировали журнал, нашли нужные записи и откатили только удаление записей в одной таблице.

DirksDR,

Для меня это звучит как 'зубная щётка это хорошо, а туалетная бумага ещё важнее'.
Если вы хотите вебинар по теме тонкой работы с журналами, то я ведь только за.

А по своей теме я бы хотел демонстрацию механизмов, при которых возникают ошибки целостности. Ведь есть журналы, wij. Где уязвимость?

Alexey Maslov,

Про журналы понятно, что это маленько из другой оперы.

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

С wij, как я понимаю, демон записи либо пишет в wij, либо пишет в базу. По крайней мере, мне кажется, так должно быть с точки зрения надежности. По крайней мере, незаписанное в wij не должно попадать в базу. Дальше, если в данные не полностью записались из буфера памяти в wij, то при восстановлении питания и перезапуске Каше эти данные лучше всего игнорировать. Т.е. если сбой произошел на фазе записи в wij, то данные wij нужно игнорировать. Если сбой произошел на фазе записи в базу, то данные wij нужно просто в базу записать заново. Т.е. я не вижу варианта, при котором данные могут потеряться. И вроде бы с неожиданной потерей питания все более-менее нормально.

А вот ситуация с потерей одного из контроллеров мне непонятна, и именно при этом обычно возникают ошибки в базе. Я не помню, правда, какой диск был во встречавшихся мне случаях: с базой или журналами, wij и каталогом Cache. Т.е. например, отстегивается диск, операционная система на это никак не реагирует, Каше отправляет данные из wji на запись в базу, часть из этих данных уходит на контроллер, часть нет? А Каше ничего не видя при этом переключает демон записи в разные режимы, которые нам в итоге даже не дадут понять что произошло? Потом она уходит в режим заморозки, сервер останавливают, меняют, например, контроллер, Но Каше не понимает, какую часть wij нужно докатить в базу, ведь операционная система приняла все данные до фриза? Что-то в таком роде хотелось бы понять, только не на уровне гаданий.

VadimFПервый вебинар "Новые возможности InterSystems Cache'/Ensemble 2017.1" состоится 18 июля c 10:00 до 11:00.Пока я разочарован.
Проблемы со звуком, как у организаторов, так и слушателей, причем, слушатели не все смогли до конца настроить звук себе.
Низкое качество звука (шумы, эхо), в том числе из-за некоторых слушателей, которые не отключили микрофоны.
Очень низкая степень интерактивности, ведущий без остановки рассказал информацию по слайдам. Возможно, было в таком случае лучше записать видео и выложить его на ютуб? Смотреть его было бы удобнее, можно делать паузы, опять же, задать вопросы в комментариях.
Отсутствие, как мне показалось, новой информации. Мне кажется, это все можно было узнать в описании релиза. Все-таки вебинар должен давать что-то, что иначе получить тяжело: практику, подробные демонстрации, общение и так далее.

Спасибо коллегам в комментариях, была пара интересных ссылок, но мало кто, как мне кажется, успел их открыть.

Alexey Maslov,
да, я помню. По зеркалу вебинар понравился и на тот момент много чего дал.

По заморозке планов ничего не понял. Посмотрел на 2017.2, в документации есть, а где в портале посмотреть замороженные планы и сравнить их с актуальными, так и не нашел.
Зато случайно в поиске попалось "Alternate Show Plans". Не нашел, где она стабильно находится, но интересно, что для одного запроса могут генериться разные планы, их можно сравнивать в теоретическом быстродействии и практическом. Правда, не понял, какой из этого прок, можно ли установить для запроса альтернативный план?

Александр Коблов,

Да, спасибо. В моей версии (Cache for Windows (x86-64) 2017.2 (Build 677U) Wed May 17 2017 20:44:28 EDT) кнопка называется "SQL Statements", и закладка "Альтернативные планы" имеет прямое отношения к замороженным запросам. Но пока с точки зрения интерфейса все это неюзабельно. С другой стороны, все равно хорошо, что заморозить можно не только текущий план, но и относительно "левый". К сожалению, нет сейчас под рукой достаточно большой базы под 2017.2, на которой можно было бы поэкспериментировать.

Альтернативные планы - прям интересная фишка. Хотелось бы попробовать ради интересе решить те задачи, где я ломал голову над кривыми планами с маленькими условными стоимостями с помощью этого инструмента и проверить на деле, насколько он удобен.

eduard93,

Жаль, что не было анонса вебинара про шардинг.