Всем привет! Мы на проекте ГИС ЖКХ используем PostgreSQL и недавно столкнулись с проблемой долгого выполнения SQL скриптов из-за быстрого увеличения объема данных в БД. В феврале 2018 года на PGConf я рассказал, как мы решали эту проблему. Слайды презентации доступны на сайте конференции. Предлагаю вашему вниманию текст моего выступления.
В рамках кампании по защите данных наших клиентов мы в Imperva рассказываем о разных методах атак на БД. Если вы не знакомы с нашим исследовательским проектом StickyDB, почитайте прошлые статьи: часть I и часть II. Там описано устройство сети ханипотов (рис. 1), которая заманивает злоумышленников атаковать наши БД, так что мы изучаем их методы и улучшаем защиту.
Рис. 1. Сетевое окружение ханипота StickyDB
Недавно мы обнаружили интересную технику в ходе атаки одного из серверов PostgreSQL. После входа в БД злоумышленник продолжал создавать полезные нагрузки из встроенных бинарников в скачанных картинках, сохранять полезные нагрузки на диск и запускать их. Как часто бывает в последнее время, злоумышленник захватил ресурсы сервера для майнинга Monero. Как будто этого мало, в процессе атаки он использовал фотографию Скарлетт Йоханссон. Ну тогда ладно. Разберёмся, как это работает!
Читать полностью »
Давным-давно, в далёкой галактике, пред-предыдущий администратор вашего SQL Server задал в нём linked server, используя специально для этой цели созданный аккаунт со сгенерированным паролем. Теперь вам с этим линком нужно что-то сделать, например перенести его на другой SQL Server; но просто так это не сделать, потому что никто не знает пароля от того аккаунта. Знакомая ситуация?
Хотя MSSQL не хранит пароли для своих аккаунтов, а хранит только их хэши, — с linked server-ами так не получится, потому что для успешной аутентикации перед внешним сервером нужно обладать паролем в открытом виде. Пароли для linked server-ов хранятся в зашифрованном виде в таблице master.sys.syslnklgns:
Но не всё так просто. Читать полностью »
Ежедневно мы соприкасаемся со многими базами данных. Практически у каждого из нас есть документы, свидетельство о рождении, паспорт, водительское удостоверение и много других. Во всех этих документах есть свой уникальный номер, по которому можно однозначно идентифицировать владельца документа.
С практической точки зрения, создавать базу данных ради неё самой, не выгодное занятие, если только вы не занимаетесь теорией баз данных.
Как правило, проектирование БД зависит от целей использования. И чем яснее цель, тем лучше и проще можно разработать проект БД. И еще добавлю, необходимо делать как можно проще. Если в целом не получается просто, необходимо разбить на более простые части.
Читать полностью »
Приветствую вновь тебя, уважаемый читатель !
Когда свои реализованные идеи, опыт, а также всю ту информацию, что не дает покоя, оформляешь в публикации, рано или поздно приходит логическая точка всему ранее написанному потоку информации. Эта статья будет отличаться от всех ранее опубликованных мною своей нестрогостью и более свободным стилем изложения текста, а также она завершит изложение всего моего накопленного опыта по MS SQL Server.
Данная статья является дополнением к статье Исследуем базы данных с помощью T-SQL, а также вкратце рассказывает о созданной базе данных по администрированию SRV и о проектах-утилитах, которые предназначены помочь в работе DBA MS SQL Server.
Читать полностью »
Условная компиляция PL/SQL позволяет избирательно компилировать участки исходного кода в зависимости от условия, как правило связанного со значением пакетной константы. Часто это используется для обеспечения совместимости приложений с разными версиями СУБД.
В декабре 2017 года такая возможность появилась и в Tibero, что позволило обеспечить ещё большую совместимость приложений между Tibero и Oracle.
Для сбора и удобного просмотра данных о том, как работает PostgreSQL (общая производительность сервера, самые медленные запросы, самые частые запросы) мы долгое время использовали отличную утилиту POWA. Однако, это решение было далеко не идеальным и нам удалось найти более удачный вариант, к тому же полностью интегрированный с нашей основной системой мониторинга.
Мы уже рассказывали о том, почему секционирование баз данных очень важно для производительности DLP-системы и как мы реализовывали его в PostgreSQL. В этой статье речь пойдет об Oracle.
Специфика использования СУБД в DLP-решениях состоит в том, что объем данных прирастает очень быстро. Их невозможно держать в оперативном архиве, и долговременное хранение – это необходимость в компании численностью свыше хотя бы 50 человек. При этом оперативный архив наполняется так быстро, что отдавать информацию в долгосрочный архив приходится раз в 2 недели или чаще. Использование только встроенных средств СУБД требует знаний и опыта. Это главная сложность, и она, в общем-то, очевидна «на берегу».
Кроме того, возникают проблемы, не очевидные сразу. Как вернуть из долгосрочного архива партицию с данными более старой версии приложения и прицепить к более свежей? Что делать, если у них разных формат хранения данных? Что делать, если подключение секции было прервано, и она «зависла» между долговременным и оперативным архивом?
История последних дней. Есть у нас два SQL Server'а (2016 c SSD диском) и Express Edition (2012 с традиционным HDD). Аппаратно оба компьютеры примерно похожи (CPU/RAM/LAN). В целом 2016 «отдает» данные в 2-5 раз быстрее, за исключением некоторого набора таблиц, для которых 2012 работает быстрее в 1,5-2 раза. Такое поведение полностью противоречит какой бы то ни было логике. Любые манипуляции с настройками базы данных только ухудшают ситуацию. 2016 все более замедляется, но только для этого набора таблиц.
Для понимания парадоксальности ситуации — на обоих серверах развернута одна и та же база (с одного и того же файла backup'a). В этой базе порядка 600 таблиц. Те 5-6 которые ведут себя удивительно ничем не отличаются от десятков подобных (по структуре и количеству записей) с которыми такой проблемы нет. На обоих «серверах» — Windows 10 с последними обновлениями (это сервера разработок, а не продуктивные). На обоих SQL Server'ах последние сервис паки (без hot fix'ов). Никакие специальные «режимы» (trace flags и пр.) SQL Server'ов не включены.
Загадка сия была велика, но мой коллега ее решил. Вы даже знаете как…
Читать полностью »
7-8 ноября 2017 на конференции Highload++ исследователи лаборатории «Рэйдикс» представили доклад «Метаданные для кластера: гонка key-value-героев».
В этой статье мы представили основной материал доклада, касающийся тестирования баз данных key-value. «Зачем их тестировать производителю СХД?», — спрóсите вы. Задача возникла в связи с проблемой хранения метаданных. Такие «фичи», как дедупликация, тиринг, тонкое выделение ресурсов (thin provisioning), лог-структурированная запись, идут вразрез с механизмом прямой адресации – возникает необходимость хранить большое количество служебной информации.
Читать полностью »
