Базы данных

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

Временные таблицы всегда прекрасно помогали разработчикам. Раньше, когда я использовал Access, я обычно создавал временные таблицы, которые удалял после решения задачи. При использовании SQL Server решить задачу можно гораздо проще. Не так ли?

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

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

SQL Server 2008 располагает множеством новых и усовершенствованных функций, но одно новшество особенно заинтересовало разработчиков -- запрос с языковой интеграцией Language Integrated Query (LINQ). Существует много разновидностей LINQ, в том числе LINQ to XML, LINQ to Entities, LINQ over Dataset (VB и C#) и LINQ to SQL. Каждая разновидность LINQ имеет собственное назначение и может функционировать независимо, но специалисты по базам данных наиболее активно обсуждают LINQ to SQL.

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

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

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

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

Корпорация Майкрософт снова выпустила новую версию сервера SQL Server, обещающую упростить жизнь администраторов баз данных. Последняя версия, SQL Server 2008, содержит множество новых функций и возможностей, значительно улучшающих администрирование.

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

Кластер серверов позволяет соединить несколько физических серверов (узлов), которые служат друг для друга партнерами в процедуре перехода на резервный ресурс. Избыточность, предоставляемая кластером, обеспечивает существенно более высокую продолжительность бесперебойной работы, необходимую для критических операций. За 13 лет работы с SQL Server™ я внедрил множество кластеров, и в каждом случае были свои особенности. Этот опыт позволил мне сформулировать ряд советов и рекомендаций, которые помогут сделать работу с кластерами проще и успешнее.

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

По нескольку раз в неделю у меня проcят совета, как эффективно обслуживать рабочую базу данных. Порой вопросы исходят от администраторов баз данных, которые применяют новые решения и ищут помощи в подгонке практики обслуживания под характеристики новых баз данных. Чаще вопросы исходят от людей, которые не являются профессиональными администраторами баз данных, но, по той или иной причине, владеют базой данных или несут за нее ответственность. Я предпочитаю называть их «невольными администраторами баз данных». Задача этой стать состоит в предоставлении учебника по наилучшим вариантам обслуживания баз данных SQL Server.

SQL Server 2005 представляет новую парадигму для языка DDL. Здесь все объекты создаются с использованием команды CREATE, удаляются посредством команды DROP и модифицируются с помощью ALTER. SQL Server 2005 не имеет отдельных хранимых процедур для изменения одного аспекта объекта, подобно процедуре p_defaultdb в версиях SQL Server 2000 и 7.0, которая изменяет определенную по умолчанию базу данных пользователя, или специальных одноцелевых команд для создания атрибутов, вроде sp_addtype. SQL Server 2000 начал движение в этом направлении с расширения функциональных возможностей команды ALTER DATABASE, позволяющей выполнять все изменения в свойствах базы данных, и с ограничения использования команды sp_dboption.

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

Не смотря на то, что секционированные таблицы и индексы всегда были неотъемлемой частью больших баз данных, призванной улучшать их производительность и управляемость, в Microsoft SQL Server 2005 появились новые возможности, упрощающие процесс разработки таких решений. Данный доклад посвящен эволюции секционирования таблиц в SQL Server: от ручного секционирования данных путем предварительного создания таблиц в качестве подготовительного шага (в SQL Server 7.0 и SQL Server 2000) до процедур реального секционирования таблиц. В SQL Server 2005 новые табличные функции секционирования значительно упрощают разработку и администрирование секционированных таблиц, в месте с тем еще более увеличивая их производительность.

Компания Microsoft делает все, чтобы превратить SQL Server в полноценный сервер приложений, который на сегодня не может считаться таковым без поддержки XML Web-служб. Можно сказать, что подобная поддержка присутствовала в SQL Server 2000 с момента выхода пакета Microsoft SQLXML 3.0, однако с тех пор прошло немало времени, а развитие технологий, связанных с Web-службами, шло очень активно. SQL Server 2005, или Yukon, представляет революционные новшества как в области поддержки XML на уровне процессора базы данных, так и в области Web-служб.

Изо всех механизмов тиражирования сведение требует особого внимания администратора, поскольку степень свободы участников в этом типе тиражирования самая высокая. Специальная база данных Distribution в сведении фактически не участвует, а вся служебная информация хранится в дополнительных объектах основных баз данных на издателе и подписчике. В этой статье я хочу кратко описать возможности SQL Server 2000, которые оказались наиболее полезными для поддержки тиражирования сведением, и рассказать об особенностях перевода сопровождаемых систем на новую версию.

Статья посвящена вопросам мониторинга семи основных счётчиков эффективности работы MS SQL Server.

Эта статья посвящена повышению производительности и эффективности репликации транзакций MS SQL Server.

SQL Server 2005 был разработан с учётом того, чтобы использовать в своей работе возможности и интерфейсы NUMA, которые поддерживаются современными серверными платформами и операционной системой Windows. Есть несколько проблем, о которых Вы должны знать при попытке запуска SQL Server на поддерживающих NUMA платформах.

В SQL Server 7/2000 нет встроенной поддержки работы с регулярными выражениями. Но SQL Server похволяет работать с COM-объектами. В VBScript (библиотека vbscript.dll) есть специальный объект для работы с регулярными выражениями - RegExp.

Max degree of parallelism (DOP) - дополнительна опция конфигурации SQL Server, с которой связано много вопросов и которой посвящено множество публикаций. В этой статье своего блога, автор надеется внести немного ясности в то, что эта опция делает и как её нужно использовать.

Горизонтальные, вертикальные, динамические и join фильтры дают возможность создать разделы данных, которые потом будут изданы.

В этой статье рассматриваются некоторые важные темы организации репликации Microsoft SQL Server: топология репликации, типы и агенты репликации. Также обсуждается Merge репликация: как создать необходимые условия для этого типа репликации и как резервировать и восстановить базы данных при таком сценарии репликации. Во время иллюстрации этой концепции, предлагается пошаговое руководство по установке процесса Merge репликации.

При работе с версиями SQL Server, которые предшествовали SQL Server 7.0, системный администратор (sa) был вынужден выделять фиксированный объем оперативной памяти для нужд самого SQL Server. Этот объем нельзя было изменить, не останавливая работу SQL Server. Если выделить слишком мало оперативной памяти, производительность могла заметно снизиться, потому что у SQL Server не хватит памяти для хранения часто используемых данных. С другой стороны, если выделить слишком много оперативной памяти (например, больше, чем имеется в распоряжении операционной системы), то SQL Server не сможет даже запуститься. А если SQL Server нельзя запустить, то нельзя запустить и процедуру, которая уменьшила бы объем выделенной памяти, произведя реконфигурацию. При работе с более ранними версиями SQL Server системный администратор должен был обладать высоким уровнем мастерства, чтобы обеспечить эффективное использование ресурсов.

В критических ситуациях, база данных может быть представлена Вам, как SUSPECT, из-за завершения неудачей её восстановления во время старта сервера, причём обычно, это препятствует любому доступу клиентов к данным. Однако, существует возможность ручного вывода базы данных из состояния SUSPECT в "bypass mode" (также называемого "emergency mode") и последующего исполнения команды SELECT или запуска программы Bulk Copy (BCP), позволяющих осуществить копирование данных в другое место, в целях их сохранения.

Microsoft SQL Server 7.0/2000 позволяет Вам проверять предназначенные для Merge репликации данные. Вы можете определить только rowcount (число строк, на которые воздействовал последний запрос) для проверки данных статьи или rowcount и сверку контрольной суммы.

Сначала, мы должны понять основы того, как организованы индексы. SQL Server организовывает индексы как Би-дерево, с одной корневой страницей, являющейся отправной точкой для построения индекса. Корневая страница может иметь указатели на две или более страницы следующего уровня индекса, и, каждая из этих страниц, может иметь указатели на множество страниц следующего уровня. Последний уровень индекса - это уровень листьев, который должен содержать все индексные ключевые значения в сортируемой последовательности. В SQL Server 2000 эта последовательность может быть или возрастающей или в порядке убывания.