SQL *

Хочу поделиться с хабрсообществом проектом из области business intelligence, которым я занимаюсь в свободное время последние полтора года.

Многие используют табличные процессоры (Excel, OpenOffice Calc и т.д.) для быстрого создания приложений, которые выполняют простые вычисления, помогают при создании отчётов или облегчают планирование. Несмотря на то, что возможности таких приложений, как правило, очень ограничены, простота табличных процессоров делает такой подход очень популярным. Речь в этой статье пойдёт о попытке расширить возможности табличных процессоров с помощью многомерной модели данных (обычно ассоциируемой с понятием OLAP), стараясь при этом не слишком усложнить работу с новым инструментом. Кому интересно читаем дальше.

Пока готовится подробный обзор функционала MS Datazen и Pyramid Analytics, мы решили разместить небольшую статью по решению локальной задачи для SQL Server Reporting Services.

Недавно, при создании отчетов в SSRS столкнулись с такой задачей:
необходимо создать два связанных отчёт так, чтобы можно было перейти из основного отчета во вспомогательный, а из вспомогательного вернуться в основной с передачей параметров.
Ограничения:
основной отчёт изначально загружается со значениями параметров по умолчанию, а все возможные значения ограничены набором из запроса.

Данная статья подготовлена Алексеем Струченко, начальником отдела оптимизации СУБД и приложений компании «Инфосистемы Джет»

Вышедшая в июле 2014 года опция Database In-Memory является самой ожидаемой и самой обсуждаемой инновацией Oracle в семействе продуктов Oracle Database. За последние несколько месяцев сотрудники компании Oracle регулярно знакомили российское оракловое сообщество с особенностями новой опции.

На Oracle Day 2014 в Москве мне выпала честь дополнить теоретическую презентацию Игоря Мельникова (Oracle) по Database In-Memory практической демонстрацией. Эту демонстрацию в полном объеме показать не удалось – оказалось не так-то просто подключить проектор к ноутбуку, соединенному с демонстрационной базой. Поэтому я решил воспользоваться трибуной Habrahabr и все-таки донести суть демонстрации Database In-Memory до сообщества.

В продолжение статьи о теории и практике миграции хранилищ данных на PostgreSQL, мы поговорим о проблемах, с которыми вы можете столкнуться при переезде с распространенной СУБД MySQL. Дабы не утомлять всех лишней риторикой, сегодняшний рассказ будет более тезисный и проблемно-ориентированный.

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

Именно поэтому в предыдущей статье я рекомендовал не тратить время на поиск серебряной пули и написать что-нибудь свое “на коленке”, что действительно работает. Данная статья призвана облегчить написание такого инструмента, указывая на потенциальные изъяны, в наличии которых вы может сравнительно быстро убедиться.

Перейдем к делу.

Всем привет! В нашем предыдущем посте про облачный сервис Cackle мы рассказали об архитектуре, технологиях и нагрузках в целом. Сегодня хотим поделиться о том, как в условиях столь сильных нагрузок и уже накопленной информации (30 000 000 комментариев с 2011 года) мы сделали подробную аналитику для системы комментариев Cackle. Наш метод сбора статистики универсальный и думаю будет интересен, в плане практического применения, всем тем, кто столкнулся с задачей разработки аналитики, но пока не совсем представляет с чего начать.

В этой статье я хочу рассказать про следующий этап развития DWH в Тинькофф Банке и о переходе от парадигмы классического DWH к парадигме Data Lake.

Свой рассказ я хочу начать с такой вот веселой картинки:



Да, ещё несколько лет назад картинка была актуальной. Но сейчас, с развитием технологий, входящих в эко-систему Hadoop и развитием ETL платформ правомерно утверждать то, что ETL на Hadoop не просто существует но и то, что ETL на Hadoop ждет большое будущее. Далее в статье расскажу про то, как мы строим ETL на Hadoop в Тинькофф Банке.

«24 Hours of PASS» — это ежегодная онлайн-конференция о MS SQL Server, проводимая по эгидой профессиональной ассоциации PASS, и длящаяся 24 часа. Вот прям буквально 24 часа: докладчики из разных частей света сменяют друг-друга в марафоне вебинаров (конечно же, это отсылка к 24 часам Ле-Мана).

Усилиями Андрея Коршиков, уже несколько лет проводится русскоязычная версия «24 часа PASS». Последняя состоялась в середине марта, и если вы ещё не успели посмотреть все 24 часа видео (кстати, вот плей-лист на YouTube), то именно для вас я и сделал этот обзор.

• SQL Server 2014 In-Memory OLTP — Сергей Олонцев
• Размер имеет значение: 10 способов уменьшить размер БД — Дмитрий Короткевич
• Внутри оптимизатора запросов: Соединения — Дмитрий Пилюгин
• Оптимизация SSAS-кубов — Евгений Полоничко
• Тяп-ляп и в продакшн! — Алексей Ковалёв
• Оффлайн-разработка баз данных и тестирование с SSDT — Андрей Завадский
• Deadlocks 3.0. Final Edition — Денис Резник
• BIML — лучший друг для SSIS-разработчика — Андрей Коршиков
• Power BI Q&A — Константин Хомяков
• Azure Data Factory — облачный ETL — Сергей Лунякин
• Все что вы хотели узнать о Workspace memory — Мария Закурдаева
• Быстрый анализ производительности SQL Server за 1,5 часа — Кирилл Панов
• Внутреннее устройство страниц и экстентов SQL Server — Алексей Князев

Недавно на Хабре появилась обзорная статья об инструментах Microsoft MAPT. Программа предназначена для проведения инвентаризации ИТ-инфраструктуры, помощи в миграции машин на новую версию ОС, оценки загруженности серверов, консолидации их на платформе Hyper-V и т.п. Мы решили рассказать о реальном опыте использования этого инструмента для решения настоящих бизнес-задач.

Задача, которая стояла перед нашей компанией, состояла в проведении точной и аккуратной инвентаризации всего ПО на рабочих станциях пользователей с последующей его рационализацией. Последняя основывается на создании так называемого MAL, или списка стандартного ПО, которое будет разрешено для использования в компании. Основная идея – управлять ПО, а именно — сократить количество ПО, проведя стандартизацию по версиям, редакциям и языкам там, где это возможно, а также учесть функционал приложений и некоторые вопросы лицензирования. Сокращая количество разрешённого ПО, мы не только экономим на лицензиях, но и уменьшаем стоимость поддержки пользовательских приложений.

Если вы интересуетесь ИТ, то вам, скорее всего, не нужно объяснять, что такое MySQL. А если вы знаете про MySQL, то наверняка вам знакомо имя Майкла Монти Видениуса. Для всех остальных и тех, кто подзабыл, напоминаем: MySQL – самая популярная в мире система управления базами данных, а Монти – её создатель, основатель компании MySQL AB, знаменитый ИТ-гуру и просто горячий финский парень.



25 мая, то есть в ближайший понедельник, Монти будет в Москве и проведёт мастер-класс, на котором поделится секретами вывода софтверных проектов на рынок, расскажет о том, как построить карьеру в ИТ, как продать компанию за миллиард долларов и начать всё сначала, приоткроет свои планы на будущее.

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

Однако, как только у нас появляется отдельная система для хранения очереди сообщений (мы используем RabbitMQ), сразу возникают проблемы с транзакционностью. Например, если мы хотим сохранить в БД отметку о том, что мы отправили сообщение в Rabbit, не так уж и просто гарантировать, чтобы отметка была сохранена только в случае успешной отправки сообщения. О том, как мы справлялись с этой проблемой читайте под катом.

Доброго времени суток, уважаемые читатели!

Данный пост будет интересен тем, кто использует SQL Server Management Studio (SSMS) при работе c SQL Server.
Речь пойдет о расширении SQL Refactor Studio для SSMS.
Данное расширение позволяет значительно сэкономить время на ежедневных рутинных операциях.

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

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

Практически ни один серьезный пентест не обходится без проверки СУБД, ведь это одна из самых популярных у злоумышленников дверей к желаемой информации и машине. В крупных проектах в качестве СУБД очень часто используется MS SQL Server. И о проверке именно его безопасности мы сегодня и поговорим. Открывать Америку не будем — опытные камрады лишь освежат свои знания, а вот для тех, кто только начинает осваивать тему, я постарался максимально подробно разложить все по пунктам.

MyISAM — основная, вернее, одна из главных (наряду с InnoDB) систем хранения данных в СУБД MySQL. При этом MyISAM таблицы повреждаются очень просто — с этим проблем нет никаких. Сложнее все повреждения ликвидировать, хотя это тоже можно сделать довольно быстро. В этом материале объясняется, как можно решить проблему с использованием myisamchk для идентификации проблемы с MyISAM и ее исправления.

Общеизвестно, что при создании таблицы в MySQL, создаются три различных файла: *.frm — формат таблицы, *.MYD (MyData) — хранение данных, *.MYI (MyIndex) — индекс. Для крупных баз данных стоит использовать InnoDB, поскольку здесь есть некоторая схожесть с Oracle и соответствующая функциональность.

MySQL — одна из самых распространенных СУБД. Ее можно встретить повсюду, но наиболее часто она используется многочисленными сайтами. Именно поэтому безопасность базы данных — очень важный вопрос, ибо если злоумышленник получил доступ к базе, то есть большая вероятность, что он скомпрометирует не только ресурс, но и всю локальную сеть. Поэтому я решил собрать всю полезную инфу по взлому и постэксплуатации MySQL, все трюки и приемы, которые используются при проведении пентестов, чтобы ты смог проверить свою СУБД. 0day-техник тут не будет: кто-то еще раз повторит теорию, а кто-то почерпнет что-то новое. Итак, поехали!

Сегодня я бы хотел поговорить о векторах атак на СУБД Oracle на разных стадиях: как прощупать слабые места базы снаружи, проникнуть и закрепиться внутри плюс как все это дело автоматизировать с помощью специализированного софта. Архитектура и возможности базы данных весьма интересны, занимательных моментов немало, а значит, немало и способов все испортить. Однако не забывай: ломать — не строить, поэтому вся дальнейшая информация предоставлена исключительно с целью выявить недочеты в защищенности тестируемых систем и повысить безопасность.

Традиционно статья написана тезисно. Более подробное содержание можно найти в приложенном внизу статьи видео с записью лекции про триггеры Oracle.

• Общие сведения о триггерах Oracle
• DML triggers
  
  • Псевдозаписи
  • Instead of dml triggers
  • Instead of triggers on Nested Table Columns of Views.
  • Составные DML триггера (compound DML triggers)
    
    • Структура составного триггера
  • Основные правила определения DML триггеров
  • Ограничения DML триггеров
  • Ошибка мутирования таблицы ORA-04091
• Системные триггеры (System triggers)
  
  • Триггеры уровня схемы (schema triggers)
  • Триггеры уровня базы данных (database triggers)
  • Instead of create triggers
  • Атрибуты системных триггеров
  • События срабатывания системных триггеров
• Компиляция триггеров
• Исключения в триггерах
• Порядок выполнения триггеров
• Включение/отключение триггеров
• Права для операций с триггерами
• Словари данных с информацией о триггерах

В данной статье хотел бы рассказать про набор полезных дополнений к Visual Studio, которые могут в значительной мере облегчить разработку баз данных на основе MS SQL Server.
Основными преимуществами использования SSDT я бы выделил следующее:

• возможность простого изменения (refactoring) схемы базы (можно переименовать колонку таблицы и все Views, Functions и Stored Procedures ссылающиеся на неё автоматически будут исправлены для отражения изменений)
• создание юнит тестов для базы данных
• хранение структуры базы данных в Source Control
• сравнение схемы/данных c возможностью генерации скрипта для приведения схемы/данных к требуемому состоянию

Безусловно на этом плюсы использования SSDT не заканчиваются, но остальное не так сильно впечатляет, как то, что упомянуто выше. Если вас интересует, как воспользоваться этими и другими преимуществами — прошу под кат.

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825
• Часть четвертая — habrahabr.ru/post/256045

В данной части мы рассмотрим

Здесь мы в общих чертах рассмотрим работу с операторами модификации данных:

• INSERT – вставка новых данных
• UPDATE – обновление данных
• DELETE – удаление данных
• SELECT … INTO … – сохранить результат запроса в новой таблице
• MERGE – слияние данных
• Использование конструкции OUTPUT
• TRUNCATE TABLE – DDL-операция для быстрой очистки таблицы

В самом конце вас ждут «Приложение 1 – бонус по оператору SELECT» и «Приложение 2 – OVER и аналитические функции», в которых будут показаны некоторые расширенные конструкции:

• PIVOT
• UNPIVOT
• GROUP BY ROLLUP
• GROUP BY GROUPING SETS
• использование приложения OVER

Операции модификации данных очень сильно связаны с конструкциями оператора SELECT, т.к. по сути выборка модифицируемых данных идет при помощи них. Поэтому для понимания данного материала, важное место имеет уверенное владение конструкциями оператора SELECT.

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825

В данной части мы рассмотрим

Многотабличные запросы:

• Операции горизонтального соединения таблиц – JOIN
• Связь таблиц при помощи WHERE-условия
• Операции вертикального объединения результатов запросов – UNION

Работу с подзапросами:

• Подзапросы в блоках FROM, SELECT
• Подзапрос в конструкции APPLY
• Использование предложения WITH
• Подзапросы в блоке WHERE:
  
  • Групповое сравнение — ALL, ANY
  • Условие EXISTS
  • Условие IN