[26.09.2010] Катастрофа (пропали данные)

MPK> Вроде все сохранилось. Спасибо! Непонятно правда что дальше делать? Как все вернуть в исходное? Опыта в таких делах не имею...

Просто создать заново тему и туда всё скопипастить :-/

au> Дата последнего файла бэкапа БД форумов: 05.10.2010 05:14

Ага, я вижу. И жду следующего утра.

Алдан-3> Непорядок (ц)

Хм. Надо будет поломать голову...

Kuznets> не тащить 10 тыс, тащить 100. на логику это вряд ли влияет.

Влияет. Т.к. performance зависит от этого. Ну всякие join начинают требовать ресурсов намного больше. Кроме того, из-за того, что много дат (expiration, start, end. through, temp) линейка действия commodity зависит от всех.

Kuznets> ну, вот такие вещи имхо надо делать на остановленной и отбекапленной системе...
Дык, делали на тестовой, но с полным набором. Вот разработка идёт на маленькой. А останавливать основную нельзя. Поскольку клиенты были со всего мира.

Kuznets> разве нельзя указать "эта таблица очень важная" или "на эту таблицу в принципе начхать"?

Не выходит. Любая таблица — это таблица. Исключение по настоящему временные, они исчезнут автоматически после закрытия сессии. Но для ручного анализа не очень удобны, т.к. сессия может оборваться по разным причинам, а данные часто получаются в результате аналитической работы в течении многих часов.

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

Дык, действий может быть много. И сознательный риск был в том, чтобы работать на живой базе. А дроп таблицы у нас произошёл не потому, что риск, а потому, что тоже нечаянно не то набрал. У Рому примерно так же. Хотел одно, а получил другое.

Kuznets> а как они вообще могут там появиться если логика изначально прописана?

Начиная с того, что не всё выражается foreign keys, куча функциональных зависимостей описывается через прикладнуху, в которой могут быть ошибки. Ну и ошибки самой СУБД никто не отменял.

Kuznets> разве ресурсы не резервируются?

Не хватает их. У нас по тому времени на системах было по физическому максимуму. Living on the cutting edge, так сказать.

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

Дык, стараются избежать. Не всегда выходит.

Мы отказались от SCO и Proliant серверов тогда, т.к. они физически не умели размещать более 100 ГБ дисков. Хотя они работали быстрее HP-х. А Sequent-ы уже переставали поддерживаться IBM. IBM R серия тоже имела проблемы с такими БД. Оракле имел, поэтому работали с Informix-м.

Алдан-3> Непорядок (ц)

Всё, прибил ссылки в голосах за пропавший период.

Mishka> Влияет. Т.к. performance зависит от этого. Ну всякие join начинают требовать ресурсов намного больше.

На Авиабазе в былые времена, когда ресурсов было много меньше, периодическое явление было. То всё летает, то в один прекрасный день, по достижении критической массы, всё ложится. Производительность нередко падает по мере роста объёма данных не линейно, а скачком с какого-то порогового значения.

Balancer>Пока кроме меня и Ведмедя никто на такую жертву не согласился, так что я и интерфейс для привязки ЖЖ пока не делал, Ведмедю и себе авторизационные данные вручную прописал.

Слушай, пожалуй ты прав, как-то некомфортно, да. Дело даже не в том, что пароли exposed, просто ненужные зависимости появляются. Я поменял пароль на LJ, удали из моей записи, pls. Извини за беспокойство, плохая была идея.

Ок, вырубил.