SQL *

При проектировании информационной системы выявляются некоторые слои, которые отвечают за взаимодействие различных модулей системы. Соединение с базой данных является одной из важнейшей составляющей приложения. Всегда выделяется часть кода, модуль, отвечающающий за передачу запросов в БД и обработку полученных от неё ответов. В общем случае, определение Data Access Object описывает его как прослойку между БД и системой. DAO абстрагирует сущности системы и делает их отображение на БД, определяет общие методы использования соединения, его получение, закрытие и (или) возвращение в Connection Pool.

Недавно, делая очередной функционал на одном из проектов, я столкнулся с немного необычными связями в реляционных СУБД, у которых, как оказалась позже, есть замысловатое название — Полиморфные связи. Что это такое, как и где их применять, я попытаюсь объяснить в данной статье.

Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.

Чаще всего deadlock описывают примерно следующим образом:
Процесс 1 блокирует ресурс А.
Процесс 2 блокирует ресурс Б.
Процесс 1 пытается получить доступ к ресурсу Б.
Процесс 2 пытается получить доступ к ресурсу А.
В итоге один из процессов должен быть прерван, чтобы другой мог продолжить выполнение.
Но это простейший вариант взаимной блокировки, в реальности приходится сталкиваться с более сложными случаями. В этой статье мы расскажем с какими взаимными блокировками в MS SQL нам приходилось встречаться и как мы с ними боремся.

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

Как вы могли видеть в предыдущем разделе, существует два способа поддержания изоляции:

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

Режимы, основанные на создании копии данных, достаточно просты для понимания и думаю не требуют особого внимания. При желании углубиться в детали их реализации, я могу предложить обратиться к не плохому описанию на MSDN. Я же хочу рассмотреть, как реализован механизм, основанный на блокировках.

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

Хочу поделиться с хабрсообществом проектом из области 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-техник тут не будет: кто-то еще раз повторит теорию, а кто-то почерпнет что-то новое. Итак, поехали!