А также почему БД больнее падать, если их администрируют программисты 
Потомучто у программеров дурная привычка лезть в БД не имея бекапа. Сто раз говорил оутсоурсерам - сначала бекап, потом sql-запрос.
Высказывание верно лишь для “кустаря”. Любой “культурный” программист сначала думает, потом делает. Не открою Америку, если скажу, что программирование - это искусство думать. Можно неделю думать, как решить задачу, а потом кодить 15 минут и готово. А можно сначала кодить месяц, потом думать, что делать с тем, что написал. 
1 лайк
=0 ничего не понял. Это у Вас что - разработка ведётся на той же базе данных на которой кто-то ещё живёт ?
Может стоит делать “как люди” - программки пишутся в соединении с одной базой данных (чистота которой мало кого волнует, и в которой по сути содержатся только описания таблиц, а никак не их содержимое)
текущее тестирование ведётся на другой машине (в которую попадает только код, готовность которого для тестирования “подтверждёна” разработчиком, и уже эта машина соединена с тестово-песочной базой данных (регулярно восстанавливаемой с бэкапа, “ибо нефиг”).
А уже финальные тесты ведутся на третьей машине (где база данных создаётся скриптами с нуля или с копии “продуктивной” базы данных), и успешно протестированный на последней машине код может использоваться в “боевых условиях”.
И главное - какое всё вышесказанное имеет отношение к “проблемам БД из-за администрирования программистами” ? (как-раз наоборот - в построенном примере бедных “заморских программистов” заставляют делать не свойственные им бэкапы, даже прежде чем запустить селект на чтение данных (не знаю зачем 
)
Ну во-первых программер программеру рознь, есть путевые ребята, которые лучше неделю подумают, а есть и “наколенники”, которые пишут черновой вариант кода, а потом две недели его вычесывают. Во-вторых я хоть больше и сетевой админ, но свои серваки с БД от любых посягательств на целостность берегу как общим ежедневым бекапом, так и бекапом транзакций. Но бывает, что ошибки обнаруживаются не сразу (например, некоторые операции совершаются раз в пол-года) или была ситуация, когда программер уверен в правильности кода, но оказываетсо “так как у вас не стоят последние обновления, то код сработал неверно упсь…”. А то, что мы не можем ставить последнее обновление,т.к. на нем перестает работать очень много из используемых сейчас функций, он забыл.
Был у нас на одном из филиалов админ-программер, дык он данные за весь день потерял,т.к. случайно запрос кинул не в одну из тестовых, а в рабочую базу.
Буквально недавно было на ithappens.ru
Был я айтишником в одном турагентстве. Как-то, шерстя базу данных, я нашёл информацию о ценах в отелях на ближайшие три года. Спрашиваю у генерального директора, как это так: то ли у нас ясновидец в штате появился, то ли отели по три года не меняют цены в условиях инфляции? Босс ответил, что данные туда попали по ошибке, и их надо удалить.
Всего один короткий запрос. Всего две забытые кавычки:
delete from prices where price_date>unix_timestamp(2009-12-31)
Сервер радостно подсчитал: 2009 – 12 – 31 = 1968. Как и было заказано, база данных грохнула цены на все даты позже 1968 секунд от начала юникс-эпохи (то есть после 0 часов 32 минут 42 секунд 1 января 1970 года). На тот момент не существовало не только самой фирмы, но даже и самого гендиректора.
В итоге все отели лишились всех цен. Вытаскивать в авральном режиме из бэкапов несколько сотен тысяч строк вручную было ой как весело…
Ну это уже к историям о том, что бывает когда админы начинают программировать
А в то, что написано на ithappens.ru - не верю, ибо бред. Грохнута ровно одна таблица, грохнута целиком … ручной работы по восстановлению ровно 0 - берётся последний полный бэкап, из него достаётся таблица и на неё докатываются все дельты после последнего бэкапа, после чего таблица копируется на своё место. Работы на час с хвостиком.
Первая самая распространённая ошибка и лежащяя на поверхности - это бэкап не делается.
Вторая тоже распространённая, но лежащяя чуть ниже - бэкап делается, но не проверяется.
Третья такая-же, как вторая - логи БД не проверяются.
Четвёртая ошибка логи ОС тоже игнорируются.
Пятая - целостность БД не проверяется.
Остальные более тонкие ошибки.
1 лайк
В 75% случаев режим создания логов - выключен.
Это как-бы не ошибка, все зависит от требования бизнеса.
РИАльные крутые прогеры, правят на риальных БД.
=0 три минуты честно пытался понять в чём бы могло заключаться требование бизнеса. Сдаюсь. В чём? ( Я как-то уже привык, что в районе моего муравейника действует стандарт на бэкапирование (при котором хранятся три последних полных бэкапа и все дельты между ними)
Второй вопрос - профессиональный. Я совершенно себе не представляю как можно “проверить бэкап” ? Насколько я понимаю его проверяет сама система при “изготовлении”, и если она чего-то не поймала, то проверить можно только установкой БД с бэкапа, а это развлечение не на пять минут.
уточнение - они бы правили, да кто ж их туда пустит
В Украине и вообщем то во всем пост-СССР очень ценятся базы данных, которые умеют исчезать за несколько секунд Не оставляя за собой логов и прочих следов своего наличия.
Я знаю реальный пример, когда рабочий день начинается с включения трех флешек с ключами (притом, третья втыкается даже не в стране, где эта схема работает) и отключение любой из них приводит к приведению в негодность рабочей БД.(естественно предусмотрен механизм криптованного резервирования)
По поводу второго вопроса - некоторые настолько беспечны, что не мониторят логи резервного копирования баз. Или бывает, зайдут в папку с бекапами - файлы есть сегодняшние и ладно, а то что размер этих файлов 50 Мб вместо положенных 2-3 гиг внимания не обратят.
Самые разные…
- Первые требование скорость больше, скорость отклика важнее.
- Место для дельт нужно…
- Восстановление информации достаточно быстро и автоматизированно…
- начальство не в курсе, а прогер решил, что так правильнее.
При восстановление бэкапа на некоторых БД не проверяется целостность данных.
Если БД восстанавливается путём пересоздание файла, скажем FireBird, получается автоматическая проверка целосности данных.
Есть ещё один пример, когда бывают проблемы - это логически непродуманная схема безопасности программ работающих с БД. Например, у меня бухгалтерия использует некий продукт, основные модули которого написаны на VBScript, XML и частично sql-вставками. Притом для работы некоторых модулей требуются права администратора БД (притом модуль стандартный). Вот и приехал ктонить с программеров, попросили его подправить чтолибо, ну он и полез крутить подобный скрипт. А потом понял, что “зря я это сделал”. Притом подобные разработки никто не проверяет.
Самое удивительное пускают.
Бизнес обычно далёк от ИТ, а прогер грит, что надо для бизнеса “быстро” и ему верят.
Ranckont - как тут уже писал ziv - слона можно трогать за разные места. В районе моего муравейника всегда есть “близкое к айти” подразделение которое и занимается допуском к БД, и все изменения с БД делаются в тестовой базе, а в продуктивную переносятся с использованием специальных механизмов, а никак не ручками.
возможно, когда изменения можно отложить в технологическое окно.
Когда-же имеется контакт с людьми, особенно далекими от “компутеров”, возможно все.
всё зависит от айти подразделения. Не знаю как сейчас, а раньше как-минимум в Свердловэнерго всё было аккуратно
Если делается бэкап, то его всегда расшифруют.
Могу только предположить, что данные не нужны были “быстро” и ошибка будет стоить несколько жизней…
Хотя Чернобыль нам грит, что и это не останавливает…