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

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

Устранение проблем производительности системы базы данных может быть непреодолимой задачей. Важно знать, в чем заключается проблема, но еще более важно понимать механизм реагирования системы на определенный запрос. На производительность ЦП сервера базы данных может повлиять ряд факторов: компиляция и перекомпиляция инструкций SQL, отсутствующие индексы, многопоточные операции, проблемы производительности дисков, узкие места со стороны памяти, процедуры обслуживания, действия по извлечению, преобразованию и загрузке и другие факторы. Использование ЦП само по себе не является проблемой — процессор предназначен для выполнения работы. Ключом к оптимальному использованию процессора является обеспечение того, что процессор выполняет необходимую работу, а не тратит время из-за плохо оптимизированного кода или оборудования с низкой производительностью.

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

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

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

Администраторы баз данных SQL Server по всему миру сталкиваются с проблемой, которая кажется вечной: устранением неполадок, основной объем которого осуществляется для обнаружения тех или иных проблем с производительностью. Даже наиболее тщательно сконструированная и протестированная система приложений испытывает изменения с течением времени, что может привести к значительным проблемам с производительностью.

Одними из самых непонятных составных частей SQL Server являются механизмы ведения журнала и восстановления. Складывается впечатление, что сам факт существования журнала транзакций и то, что неправильное управление этим журналом может приводить к неполадкам, ставит в тупик многих «невольных администраторов баз данных» (DBA). Почему журнал транзакций может неограниченно увеличиваться в размере? Почему в некоторых ситуациях требуется слишком много времени для того, чтобы база данных стала доступной после сбоя системы? Почему невозможно полностью отключить ведение журнала? Почему не удается надлежащим образом восстановить базу данных? Что из себя представляет журнал транзакций, и зачем он существует?

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

Резервное копирование баз MySQL. Гораздо более сложной представляется задача создания копии такой динамичной структуры, как база данных MySQL.

Вообще, почти все хостинг-провайдеры производят резервное копирование всех файлов пользователей. Однако, не стоит забывать о том, что провайдеры делают backup, в основном, для себя, на случай аварии у себя. Именно по этой причине пользователи в условиях хостинга могут, конечно, рассчитывать на восстановление в случае удаления каких-то данных по вине самого пользователя, но вовсе не факт, что провайдер сделает восстановление MySQL-базы сразу по получению запроса. Лучше делать для себя копию и в случае чего ее использовать. Можно даже периодически копировать этот свой backup на другую, не провайдерскую машину - так надежнее, на всякий случай.

Начиная с версии 4.0, сервер MySQL поддерживает преобразование кодировок символов. Эта статья рассказывает о том, что такое кодировки, сопоставления и о том, как работать с ними применительно к серверу MySQL.

Введение

Начиная с середины 90х, ext/mysql служило основным мостом между PHP и MySQL. Хотя в нем имелись недостатки и проблемы росли с годами, в общем, ext/mysql делал свое дело неплохо и шел в ногу с изменениями как в PHP, так и в MySQL.

Однако с появлением PHP 5 и MySQL 4.1 все изменилось - начали образовываться несколько достаточно обширных трещин.

В ext/mysql имелись "достоинства, оказавшиеся недостатками": в первую очередь это mysql_pconnect(), подключение по умолчанию и автоматическое подключение. Кроме того, проявились несовместимости между функциями ext/mysql и теми, что поддерживались клиентской библиотекой MySQL, на которой основаны и ext/mysql, и ext/mysqli.

В попытке исправить эти расхождения, Георг Рихтер создал очередное расширение PHP 5, которое поддерживает новые возможности MySQL 4.1+. Это расширение получило название ext/mysqli, где 'i' заменяет одно из слов: improved(улучшенное), interface(интерфейс), ingenious(изобретательное), incompatible(несовместимое) or incomplete(неполное).

Служба каталогов Microsoft Active Directory стала одним из важнейших компонентов многих IT-сред. Одной из важнейших возможностей службы Active Directory является поддержка групповых политик, позволяющих администраторам централизовать управление контроллерами, серверами и рабочими станциями домена.

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

Возможности делегирования, предусмотренные в службе каталогов Active Directory, весьма значительны; они решают ряд проблем защиты и упрощают задачи управления. Грамотное делегирование прав в службе Active

Directory® позволяет регламентировать применение в среде определенных ролей, уменьшить вероятность и нейтрализовать последствия административных ошибок, реализовать в существующей инфраструктуре принцип наименьших привилегий. В то же время, многие организации, опирающиеся в своей работе на службы Active Directory, до сих пор не воспользовались потенциалом функции делегирования. Отчасти это объясняется кажущейся сложностью разработки модели делегирования в корпоративной среде службы Active Directory. Действительно, сформировать модель делегирования, отвечающую индивидуальным потребностям предприятия, сложнее всего, но с другой стороны, существует множество простых моделей, которые можно реализовать в большинстве ИТ-сред лишь с незначительными изменениями.

Active Directory — одна из самых критичных служб в сети Windows. Чтобы свести к минимуму время простоя и снижение производительности, очень важно иметь эффективные планы аварийного восстановления при неполадках в Active Directory. Это может показаться очевидным, но

просто поразительно, сколько администраторов не имеют плана восстановления при возникновении одной из наиболее вероятных проблем с Active Directory®: случайного удаления данных.

Случайное удаление объектов — одна из наиболее распространенных причин сбоя службы. Когда я провожу семинары или конференции, я часто спрашиваю, сталкивался ли кто-нибудь с неполадками в Active Directory из-за случайного удаления данных. И каждый раз почти все поднимают руку.

Чтобы понять, почему так сложно проходит восстановление данных, сначала следует понять следующее: как Active Directory хранит и реплицирует объекты, и в чем заключается механизм полномочного и неполномочного восстановления.

Существует множество установок безопасности, которые могут быть сконфигурированы в одном Объекте Групповой Политики (Group Policy Object). Эти установки ранжируются от контроля аккаунта Администратора для контроля LDAP подписания требований клиента. При таком большом количестве защитных установок очень важно понимать функционирование и режим работы, который не так очевиден, как можно было бы себе представить. В декабре 2004 года я написал статью про “Осуществление групповой политики защитных установок ”, которая даст вам некоторый детальный взгляд изнутри на то, как защитные установки могут применяться в обычной среде. В этой статье я раскрою суть концепции (включая некоторые регистровые “хаки”), а также некоторые наиболее общие сценарии, в которых установки безопасности ведут себя не так как положено.