SQL *

Часто возникает задача восстановить базу по цепочке бэкапов на резервном/тестовом сервере, на котором непосредственный бэкап базы не проводился, отсутствуют записи в msdb, но есть сами бэкапы, снятые с продуктивного сервера. Вариант с восстановлением копии базы msdb может не подойти если должны существовать разные наборы джобов для основного сервера и того, на котором мы планируем восстановление. Если файлов с бэкапами немного, то восстановить логический порядок следования файлов нетрудно, особенно если бэкапы принадлежат логшиппингу. В этом случае все тривиально — в имени файла хранятся и время, и дата (стоит только помнить, что время в именах файлов хранится в UTC). Но что делать, если в бэкапах нет структуры или файлов очень много, и организовать их простым способом не представляется возможным или как можно просто определить начиная с какого файла логшипинга начинать донакатку?

Здравствуйте!

Прежде всего, хотелось бы отметить 2 момента:
— данная статья описывает алгоритм работы, а не как оптимизировать конкретные SQL-запросы;
— описываемый в статье подход не актуален для «производительного» железа, речь пойдет о том, как удалось повысить «отзывчивость» интерфейса приложения интенсивно работающего с БД на бюджетных смартфонах под управлением Android;

NewSQL

Начало

Сегодня очень легко наблюдать стремительный рост данных в интернете. Согласно одной оценке, данные, созданные в 2010, составляют приблизительно 1,200 ЭБ (10¹⁸ байт) и вырастут почти к 8,000 ЭБ к 2015 в Интернете, являющимся основным поставщиком данных к потребителю.

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

Пока программисты всего мира устраивают глобальные Holywars на тему: «SQL vs NoSQL», крупные компании, такие как Google и Facebook со своей миллиардной аудиторией всеми силами борются с нехваткой мощностей и предельными работами СУБД. Несмотря на появление новой технологии NoSQL, которая позволяла легко масштабировать данные, она так и не решила вопросы связанные с соответствием операций требованиям ACID (atomicity, consistency, isolation, durability — «атомарность, непротиворечивость, изолированность, долговечность») — стандарта, который гарантирует точность выполнения оперативных транзакций средствами СУБД, даже если работа системы прерывалась. На фоне всего этого компания VoltDB при поддержке нескольких других компаний, начали разрабатывать с чистого листа новый opensource проект под название NewSQL, сочетающий в себе лучшие стороны SQL и NoSQL.

Этот пост для тех, кто сталкивался с проблемой производительности, при расчете медианы в OLAP кубе.
Одним из главных достоинств OLAP технологии является скорость получения результатов при обращении к базе. Расчеты происходят «на лету». Однако с медианой, не все так просто.
Для справки: медиана — вид средней. Это величина, которая находиться в середине ряда значений отсортированного по возрастанию. Например, для ряда значений {1, 2, 5, 6, 9} медианой является 5.

Рассмотрим ситуацию на примере OLAP сервера от Microsoft — SSAS 2008 (SQL Server Analysis Services).

Предисловие

Я сертифицированный тренер Microsoft. И уже давно преподаю разные курсы для системных администраторов. На обучение приходят разные люди: от начинающих админов до высококвалифицированных системных администраторов. Цели новичков понять легко: знакомство с продуктом и получение навыков его настройки. А зачем приходят на курсы опытные администраторы? Именно на этот вопрос я и постараюсь ответить. Не хочу употреблять какие-то общие фразы, а хочу показать конкретные примеры того, чему научились давно работающие специалисты на моих курсах. Я напишу несколько примеров по Windows Server и SQL Server.

В данной заметке я покажу, как запускать DBDeploy из скрипта Gradle.

О чём это вообще?

Возможно, вы уже слышали о версионированной миграции структуры баз данных. Об этом писали на хабре. DBDeploy — один из самых простых и известных инструментов, позволяющий легко установить все последние изменения в базе данных на любом инстансе и любой девелоперской машине. А Gradle — модный ныне инструмент для сборки проекта (как Ant и Maven, только лучше). О нём тоже уже писали.

И в чём вопрос?

Вопрос в том, как запускать DBDeploy из скрипта Gradle? У DBDeploy есть таски для Ant и плагин для Maven, но пока ещё нет плагина для DBdeploy (точнее, он в зачаточном состоянии). Немного потыркавшись, я пришёл к выводу, что самый простой способ — это использовать тот самый Ant таск DBDeploy из скрипта Gradle (здесь описано, как из gradle-скрипта использовать любые Ant-таски). Рассмотрим пример.

Введение

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

Более сложная цель

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

Все началось с того, что на сайте codeforces.ru в очередном Codeforces Round я увидел интересную задачку “Скобочная последовательность” и решать ее “неинтересным способом” никак не хотелось.

Вкратце условия задачи сводятся к нахождению в строке, состоящей только из символов «(», «)», «[» и «]», правильной cкобочной последовательности, содержащей как можно больше скобок «[».

Это вторая часть цикла про то, как устроена SQL Database. В первой части речь шла об архитектуре SQL Database, во второй части продолжим этот обзор с фокусом на масштабирование и некоторые особенности разработки для SQL Database.

Обеспечение масштабируемости в SQL Database

Одним из наиболее значимых преимуществ размещения баз данных в среде SQL Database являются встроенные функции обеспечения масштабируемости. При необходимости можно добавить дополнительные базы данных. Два компонента SQL Database обеспечивают масштабируемость за счет постоянного отслеживания рабочей нагрузки на каждом из узлов. Первый компонент — Engine Throttling (регулировщик нагрузки на ядро), который защищает сервер от перегрузки. Второй компонент — Load Balancer (балансировщик нагрузки), который следит за тем, чтобы сервер не работал постоянно в режиме повышенной производительности.

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

Windows Azure предлагает как NoSQL хранилища, так и SQL-реляционные хранилища. NoSQL хранилища – это, например, Windows Azure Tables (ключ\значение) или BLOB-объекты (двоичные данные такие, как фото, видео, документы и т.п.). К реляционным хранилищам относится SQL Database (ранее SQL Azure).

Часть 1
Часть 3

В этой части будут затронуты непростые вопросы использования SQLite через работу с его программным интерфейсом (API).

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

В сложных комплексных системах часто встаёт вопрос интеграции данных из разных источников.
Такие системы получили название интегрированных, федеративных или мультибаз.

В СУБД Caché такая интеграция осуществляется с помощью специального шлюза (Caché SQL Gateway), который использует в своей основе ODBC/JDBC соединения к внешним источникам данных. Причём под источником в данном случае можно понимать не только СУБД, так как есть JDBC/ODBC драйвера для MS Excel, DBF, текстовых файлов, графических файлов, WMI и т.д.

Caché Monitor

Если при разработке или использовании вашего приложения на Caché вам часто приходится выполнять SQL-запросы, а функциональности SQL-менеджера из Портала Управления Caché или SQL-оболочки из терминала Caché вам недостаточно, то советую обратить внимание на приложение Caché Monitor.

Альтернативный SQL-менеджер разработал Андреас Шнайдер — разработчик из Германии.
Это кроссплатформенное Java-приложение кроме выполнения SQL-запросов предоставляет следующие возможности:

Если бы мне пришлось писать книгу о том, как создавать немасштабируемые приложения Oracle, первая и единственная ее глава называлась бы «Не используйте связываемые переменные».
Том Кайт, вице-президент Oracle

Недавно на Хабре появилась статья от AlexanderPHP «SQL injection для начинающих. Часть 1». По ее содержимому и комментарием к ней может создаться впечатление, что у многих разработчиков нет понятия, что такое связываемые переменные, зачем ими следует пользоваться и какие преимущества они дают. Попытаюсь в данной статье пролить небольшой свет на данные вопросы.

 

С давних времен человечество занималось тем, что накапливало информацию, анализировало и хранило её в каком-либо виде, чтобы потом передать потомкам. Эволюция нашего сознания смогла стать возможной во многом благодаря именно этому — новому поколению людей не надо было постигать то, что уже было постигнуто до них. Начиная с древнейших носителей информации – египетских папирусов и шумерских табличек с клинописью, человечество накапливало всё больший и больший объем информации. В истории человечества были времена, когда в результате войн и катаклизмов часть уже накопленных знаний уничтожалась или исчезала, и тогда прогресс останавливался, а человечество отбрасывалось назад в своем развитии. Настоящей революцией и прорывом стало открытие технологии массового книгопечатания, которое позволило распространять информацию на большую аудиторию, что в свою очередь привело к взрывному росту в науках, искусстве, а также вывело сознание всего человечества на более высокий уровень. Развитие технологий в ХХ веке привело к появлению новых носителей информации – перфокарты, перфоленты, жёсткие магнитные диски и т.п. Всё большие и большие объемы информации переносились из гроссбухов на электронные носители. Возникла потребность в организации и управлении доступа к этим данным – так появились первые СУБД.

Реляционная модель данных, предложенная в 1970 году Э.Ф. Коддом, надолго задала тенденцию в развитии баз данных и позволила полностью отвечать требованиям бизнеса до сегодняшнего момента. С 1970 года реляционные базы данных прошли большой путь и приняли много вызовов, встававших на их пути. Постоянно растущие объемы данных привели к появлению методов, способных обеспечить более быстрый доступ к необходимым данным – индексы, хранение данных в отсортированном виде и т.п. Эти методы вполне успешно справлялись со своей задачей, да и до сих пор не потеряли своей актуальности. Однако стремительное увеличение объемов носителей информации и удешевление стоимости хранения данных привело к тому, что объемы баз данных в десятки терабайт не являются уже чем-то необычным и воспринимаются, как обычное явление. Бизнес не может допустить, чтобы эти данные лежали «мертвым грузом», так как всё возрастающая конкуренция в мире заставляет его искать новые подходы к освоению сферы своей деятельности, ведь по крылатому выражению – «Кто владеет информацией, тот владеет миром». Если говорить о времени, то счет идет не на дни, или даже часы, а скорее на минуты – кто сможет быстро получить необходимую информацию, тот и выиграет.