(Возврат на основную страницу)

Содержание номера за Январь 2010 год

SQL Server
для администраторов

Февраль 2010
№ 2 (44))

Ричард Моррис Дональд Кнут: гик недели

 А. Гладченко Основы репликации SQL Server 2008. Часть 3

 Барри Кинг Секционирование в выпуске SQL Server, отличном от Enterprise Edition

 Юсеф Эхтиари Некоторые примеры использования XML

Добавьте специфики в вашу базу данных Model на SQL Server

 Артур Фуллер Чем можно заменить строковые индексы? Есть хеширование!

Умножение и деление чисел типа NUMERIC

 Алекс Гринберг Как обойти отсутствие массивов в SQL Server 2000

Дональд Кнут: гик^* недели

Дональд Кнут — выдающийся человек. Он известен не только как создатель концепции «грамотного программирования» (Literate Programming) и автор самого значимого руководства по алгоритмам программирования, но и как человек, полностью спроектировавший и разработавший одну из самых популярных систем компьютерной верстки — вплоть до идущих с ней в комплекте шрифтов.
А еще он является одним из первопроходцев в области использования программного обеспечения с открытым исходным кодом. Кнут — человек обаятельнейший, увлеченный — сочетает в себе глубокие познания в истории, музыке, живописи и математике с совершенно уникальным пониманием сути искусства программирования.

Говорят, что на стиль предпринимательских компаний часто накладывает отпечаток личность основателя, и для Microsoft это справедливо более, чем для кого бы то ни было. Билл Гейтс всегда и блистал, и зазнавался; он всегда был и превосходным предпринимателем, и игроком, нацеленным на победу любой ценой, — таким же, как и его компания.

Огромное количество людей боготворит Гейтса; в то же время, есть люди, невероятно почитаемые самим Гейтсом, и один из таких людей — легендарный американский математик и специалист в области информатики Дональд Кнут (рис. 1). Однажды Гейтс сказал о его самой известной книге «Искусство программирования» (The Art of Computer Programming) так: «Если вы считаете себя действительно хорошим программистом... прочтите книгу Кнута “Искусство программирования”... Вам определенно следует прислать мне резюме, если вы сможете дочитать ее до конца». Немало хвалебных слов было сказано в его адрес, но особо стоит отметить случившееся в конце 1990­х годов включение «Искусства программирования» в список двенадцати лучших физико­математических монографий по версии журнала American Scien­tist наряду с трудом Дирака о квантовой механике и Эйнштейна — о теории относительности.

Кнут всегда считал этапы написания «Искусства программирования», начатого в 1962 году и изначально задумывавшегося однотомным, главной работой своей жизни. Широкую известность получило его письмо (от которого он отрекается) одному из основателей Google и его бывшему студенту Сергею Брину следующего содержания: «Электронная почта — это замечательное изобретение для людей, не желающих терять общей картины происходящего. Но не для меня: я стараюсь, скорее, сосредотачиваться на отдельных деталях этой картины. То, чем я занимаюсь требует долгих часов изучения и непрерывной концентрации».

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

За сорок семь лет прошедших с момента начала работы над книгой, во многом определившей современное программирование и в той же мере определившей жизнь автора, Кнут был удостоен множества премий и наград, включая Премию Киото (1996), Премию Тьюринга (1974) и Национальную научную медаль (1979). Парадокс заключается в том, что сейчас Кнут фактически выбыл из рядов специалистов в области информатики — виной тому его любовь к музыке (его дом выстроен вокруг двухмануального органа, спроектированного им самим); по его словам, он собирается вернуться к музыке сразу же по окончании работы над последним, седьмым томом «Искусства программирования»: «В наши дни люди редко судят о специалистах в области информатики с позиций красоты и интереса; чаще нас меряют долларами».

Кнут родился в Милуоки, штат Висконсин; музыке он предпочел изучение физики в Кейсовском технологическом институте. Там он руководил баскетбольной командой и даже применил свой талант для выведения формулы полезности каждого игрока. В 1963 году в Калифорнийском технологическом институте ему была присуждена степень доктора философии по математике.

Уже в ранге первопроходца в области информатики, в 70­х годах Дональд Кнут взял перерыв в работе над «Искусством...» и уделил это время разработке системы подготовки документации TeX, ныне ставшей общепризнанным стандартом для подаваемых на публикацию исследовательских работ по математике и естественным наукам. Его творческая плодовитость этим не ограничивается: он также известен как автор научно­фантастического романа «Сюрреалистические числа: как два бывших студента занялись чистой математикой и обрели абсолютное счастье» (Surreal Numbers: How Two Ex­Students Turned On to Pure Mathematics and Found Total Happiness (1974), основанного на системе счисления, введенной математиком Джоном Конвеем.

Р. М.-Когда вышел первый том «Искусства программирования», чувствовали ли вы, что говорите от лица нового поколения специалистов в области информатики? Было ли у вас ощущение, что книга станет настоящим кладезем идей?

Д. К.-Мне помнится, я считал себя говорящим скорее от лица «старого поколения специалистов в области информатики»: они сами не пытались изложить свои действительно замечательные идеи с нейтральной точки зрения, но, напротив, стремились навязать окружающим свое мнение.

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

Р. М.-Больше всего, разумеется, меня интересует ваша работа над «Искусством программирования», но сперва я задам пару вопросов о творческом процессе в целом. Много ли вы вносите исправлений и когда понимаете, что мысль изложена верно?

Д. К.-В старших классах школы и в колледже мне приходилось много писать, так что практики в выражении собственных мыслей у меня достаточно. Действую я всегда следующим образом: не откладывая в долгий ящик, я набрасываю первый черновик, сразу же его выкидываю и начинаю сначала, когда понимаю, что же именно я хочу сказать. Из первого, самого подробного рукописного варианта я многое вымарываю и вычеркиваю. Затем я набираю этот текст, поправляя стиль изложения, ритм и темп, после чего я откладываю его в сторону и возвращаюсь к нему через некоторое время, вычитываю и правлю, пытаясь сделать его максимально понятным для человека, который увидит его впервые. Жаргонных слов я избегаю и использую их только в случае крайней необходимости. Я стараюсь делать предложения «живыми» и стремлюсь передать чувство открытия чего­то нового, которое у бывает у меня, когда я впервые знакомлюсь с материалом.

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

Р. М.-Что заставляет вас взяться за перо? Идея, образ, ситуация, событие, фраза или что­то еще? Принимаясь за работу, пытаетесь ли вы взглянуть на нее глазами читателя?

Д. К.-Обычно я пытаюсь вспомнить, что показалось мне ключевым, когда я начал знакомиться с той или иной темой. Самое важное — иметь про запас пару хороших примеров, которые можно связать с абстрактной идеей. Если пример будет слишком пространным или чересчур специфическим, у большого числа читателей пропадет внимание и интерес. Так что, мне приходится тратить довольно большое количество времени только на поиск понятных и в то же время полезных примеров. Позвольте, я приведу пример таких примеров. Однажды я потратил целый месяц — даже два месяца — пытаясь сочинить пример, связанный с игрой в бейсбол. Я написал громоздкую программу, чтобы проверить этот пример и сочинил с дюжину забавных задач для решения читателями.

У меня была большая диаграмма, которую предполагалось разместить на разворачивающейся вклейке. Я знал — поклонники бейсбола это точно оценят. Но, в конце концов, я от нее отказался и она больше никогда не увидит свет; я понял, что она будет интересна, по большому счету, только людям, которым нравится бейсбол, но как наглядное пособие для изучающих информатику она вряд ли подойдет.

Тем более, что британских читателей, вроде вас, этот пример заинтересовал бы примерно в той же степени, что меня — пример, основанный на крикете. А вот год назад, когда я искал пример, который бы проиллюстрировал то, что специалисты называет «решением 2SAT за линейное время», нигде, ни в одном источнике я не нашел объяснения причины, по которой эта проблема вообще нуждается в решении. И вот тогда мне пришла в голову идея примера с составлением графика выступлений комиков в отелях Лас­Вегаса; и — вуаля! — мы решили 2SAT и сделали это в довольно занимательной манере. (Описание того, что такое 2SAT, можно найти по ссылке http://en.wikipedia.org/wiki/2­satisfiability. — Прим. ред.)

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

Р. М.-Влияет ли ваше эмоциональное состояние на рабочий процесс?

Д. К.-Я не могу излагать материал «живо», если сам чувствую себя вяло. В этом смысле мне, похоже, везет, и я в основном счастлив — спасибо любящей семье и друзьям. Я не использую кофе или другие стимуляторы для обретения творческого настроя. Если я устал — я лучше немного посплю. Для работы мне нужна тишина и полное спокойствие; вот почему я прекратил пользоваться электронной почтой 20 лет назад. Иногда по утрам, когда я понимаю, как много еще предстоит сделать, бывает очень трудно приняться за работу; но как только я уцеплюсь за какую­нибудь техническую проблему, меня наполняет жизненная сила и тогда весь день я бываю настолько взвинчен, что с трудом засыпаю ночью.

Тогда я принимаюсь за какое­нибудь легкое чтение (Дороти Сэйерс, Ян Флеминг, Фредерик Форсайт, Агата Кристи — видите, как я люблю британских писателей — а еще Рэймонд Чандлер, Рекс Стаут, Герман Воук, Сара Парецки и т. д.). Часто хватает всего пары абзацев — и я уже настолько утомлен, что потом всю ночь сплю как младенец.

Р. М.-У вас особое отношение к музыке, в частности, к игре на органе. Слушаете ли вы музыку во время работы и не слишком ли вас это отвлекает?

Д. К.-Для разных ситуаций подходит разная музыка. Так например, я обнаружил, что вычитка мне удается особенно хорошо — гораздо лучше, чем в полной тишине — под камерную музыку Телемана; а вот когда играет Бах, я вообще не могу вычитывать текст. Для составления алфавитного указателя книги иногда замечательно подходит Брамс: я печатаю в такт его литаврам. Раньше, когда я работал на печатной машинке, большую часть «Искусства программирования» я печатал под аккомпанемент фильмов вроде «Двойной страховки» (Double Indemnity).

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

Р. М.-Насколько подробны дневники, которые вы вели в это время и собираетесь ли вы их когда­нибудь опубликовать?

Д. К.-Я веду технический дневник, в который просто записываю отчеты о проделанной за день работе и еще пару предложений о других занятиях. Выдержки из дневника я приводил в качестве примера в факсимиле в главах 24 и 25 моей книги «Цифровая типография» (Digital Typography). Эти дневники хранятся на моем компьютере, так что я всегда легко могу найти соответствующую запись и узнать, что делал много лет назад; например, если мне нужно будет вспомнить, когда я был в Лондоне, легко найти записи, в которых значится, что я летал туда 4 мая 1965 года, 31 мая 1967 года и 19 мая 2009 года. Думаю, когда­нибудь я выложу эти дневники в Сеть — в них нет ничего секретного. Но боюсь, они будут гораздо скучнее, чем, например, дневники Льюиса Кэрролла.

Р. М.-Как вы думаете, можно ли научить человека глубокому анализу и методологии решения определенных проблем?

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

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

Р. М.-Занимались бы вы компьютерами, даже если бы это не приносило никакой экономической выгоды?

Д. К.-Спасибо, что задали этот вопрос. Информатика всегда привлекала меня, потому, что она предполагает использование различных красивых комбинаций и схем; это похоже на то, как танцоры наслаждаются хореографией. А кроме того, вопросы вроде «Что можно вычислить эффективно?» действительно интересны и дают пищу уму. В то же время, я никогда не понимал, почему люди платят за компьютеры и никогда не пытался заработать на том, что я делаю.

Как учитель, я вижу свою задачу в том, чтобы донести до людей некие важные сведения и получаю за это достойное вознаграждение. Как писатель же, я никогда не задумываюсь о том, какие книги будут продаваться лучше всего; я пытаюсь представить, какие книги людям нужны или какие книги будет интересно читать и писать.

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

Если бы мне пришлось зарабатывать программированием себе на жизнь или если бы я считал себя вожаком, а не рядовым членом стаи, то мое отношение, несомненно, было бы другим. Но я предпочел бы остаться специалистом в области информатики, даже если бы эта сфера была полностью изъята из экономики.

Поэтому меня огорчает тот факт, что люди оценивают нашу работу с позиций экономической выгоды, а не интеллектуального эффекта. Я завидую астрономам: ведь принято считать, что они изучают звезды, потому что звезды красивы и интересны?

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

Р. М.-На своем сайте вы упоминаете книгу Дугласа Престона «Богохульство» (blasphemy), которую кратко можно охарактеризовать как частный случай столкновения науки и религии с вкраплениям политики. Считаете ли вы, что с помощью науки и техники человек с большей вероятностью придет к Богу, нежели без них?

Д. К.-Я бы попробовал взглянуть на этот вопрос с другой стороны: какой по мнению Бога способ преображения духовной стороны человека к лучшему является наиболее эффективным? «Один размер не подойдет всем». Не хочу раскрывать сюжет книги Престона, но могу заявить, что, на мой взгляд, именно последняя фраза этот роман шедевром.

Р. М.-Согласны ли вы с мнением Рэя Курцвейла о том, что однажды мы сможем перепрограммировать человеческую природу с помощью нанотехнологий и использовать наноботы — устройства размером с клетку, которые будут циркулировать в нашей крови — чтобы делать собственную жизнь сколь угодно долгой? Или все же нелепо на это надеяться?

Д. К.-Я никогда не был хорош в предсказаниях, но все же отвечу на ваш вопрос. Я глубоко уважаю Курцвейла — играл как­то раз на рояле, сделанном им для Марвина Мински, и еще мне довелось поэкспериментировать с поистине удивительным устройством оптического распознавания символов, сконструированного им задолго до появления чего­то подобного у других. Лично мне кажется, что он несколько недооценивает насколько велик разрыв между тем, что мы знаем сейчас и тем, что требуется узнать для того, чтобы такие устройства продления жизни стали реальностью; с другой стороны, Рэй знает куда больше, чем я.

Я глубоко убежден в том, что долгая жизнь — далеко не самое важное; и я хотел бы жить, пока могу приносить другим пользу, но не более того. Не будучи сторонником эвтаназии, я не хотел бы, тем не менее, чтобы меня подключали к аппарату искусственного поддержания жизни, если будет зарегистрирована смерть моего мозга.

Как сказал Спортинг Лайф из оперы Гершвина «Порги и Бесс»: «Мафусаил прожил девятьсот лет. Но разве это жизнь? Да какая девка ляжет в постель с тем, кому девятьсот лет?» Я не очень хорошо помню либретто, но, думаю, вы поняли мою мысль.

*-Geek (англ.) — «человек, живущий компьютерами и всем, что с ними связано» (http://www.rsdn.ru/forum/dictionary/1415893.1.aspx).

Основы репликации SQL Server 2008. Часть 3*

Подготовка к репликации

Подготовка системы к реализации репликации данных должна начинаться с этапа тщательного планирования. Вначале необходима адаптация баз данных к требованиям репликации, а также адаптация коммуникации серверов к порождаемой репликацией нагрузке. Планирование должно также включать вопросы организации информационной безопасности транспорта репликации и хранения данных, а также планов резервирования и восстановления репликации и данных. Очень полезно иметь подробное описание и план внедрения репликации и запуска ее в эксплуатацию. Адаптации к репликации, в первую очередь, подлежит схема данных. Например, если для организации ссылочной целостности в базе данных используются поля IDENTITY, и приложение подразумевает ввод новых записей не только на издателе, но и на подписчике, нужно предусмотреть меры по разделению диапазонов IDENTITY между подписчиками и издателем или заменить столбцы IDENTITY на столбцы глобальных уникальных идентификаторов — GUID.

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

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

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

Во­первых, все таблицы, включенные в репликацию транзакций, должны иметь первичные ключи.

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее распространенной сетевой средой локальных вычислительных сетей сегодня является Ethernet. Практически повсеместно используются сети пропускной способностью 1000 или 100 Мб/сек. Необходимо помнить и об ограничениях, которые накладывает такая сеть. Сети Ethernet являются коллизионными, т. е. возникающие одновременно в сети два пакета отклоняются оборудованием сети и повторяются через случайный промежуток времени, разный для каждого из пакетов.

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

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

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

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

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

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

Плохо спланированная локальная сеть или недостаточная пропускная способность интернет­канала также могут создать проблемы при организации репликации. Для своевременной реакции на возникновение проблем репликации стоит наладить постоянный контроль утилизации сетевых ресурсов и обеспечить возможность диагностики всей топологии вашего внешнего и внутреннего коммуникационного канала для репликации.

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

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

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

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

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

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

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

Разнесение по времени сеансов разных подписчиков также позволит сократить взаимное влияния их трафика друг на друга. Для предотвращения приводящего к затоплению сети поведения агентов репликации можно отказаться от повторных попыток синхронизации при неудаче.

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

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

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

Сверка может выполняться со всеми, либо только с одним подписчиком, это указывается для SQL Server 2000 в специальном диалоговом окне программы Enter­prise Manager, которое называется: «Validation Op­tions». Существует три вида сверки, которые отличаются степенью нагрузки на серверы и каналы связи.

Можно выбрать быстрый подсчет строк (самый щадящий метод), точный подсчет строк (для сверки с другими версиями) и самый «тяжелый»способ — вычисление контрольных сумм. Сверка может выполняться не только вручную, но и автоматически, по расписанию. Кроме того, если сверка выявит расхождения, можно настроить автоматическую повторную инициализацию для не прошедшего сверку подписчика. Для этого в SQL Server 2000 существовала опция: Re­ini­tialize Subscriptions Having Data Validation Failures Agent.

В состав системных хранимых процедур входят три специализированные процедуры, которые предназначены для реализации сверки данных. Хранимая процедура sp_article_validation предназначена для сверки одной статьи и применима в репликации транзакций (для некоторых версий она применима и для репликации снимков).

Процедура sp_publication_validation сверяет всю публикацию репликации транзакций (для некоторых версий она применима и для репликации снимков). И еще одна процедура применима для всех типов репликации и позволяет осуществлять сверку таблиц или индексированных представлений. Называется эта системная хранимая процедура: sp_table_vali­dation. Ее нельзя применять для таблиц, публикуемых издателем Oracle.

Развитие репликации

Репликация не стоит на месте, она постоянно развивается, и новшества появляются не только в новых версиях, но и буквально в каждом сервисном пакете. Наиболее значимый шаг был сделан еще в SQL Ser­ver 7.0. В следующей версии SQL Server 2000 к четвертому сервисному пакету репликация заработала очень стабильно и надежно.

В SQL Server 2005 появилась целая серия новинок, одной из ожидаемых была репликация DDL (команд языка определения данных: ALTER TABLE, ALTER VIEW, ALTER PROCEDURE, ALTER FUNCTION и ALTER TRIGGER). Для предыдущих версий SQL Server поддерживал только добавление или удаление столбца статьи. Это нововведение позволяет существенно упростить изменения схемы публикуемой базы данных. Теперь изменения схемы можно выполнять с помощью программы SQL Server Management Studio, запуская в окне запроса инструкцию DDL из состава языковых конструкций Transact­SQL, или можно использовать объекты SQL Management Objects (SMO) в собственных приложениях.

DDL команды, по умолчанию, будут растиражированы всем подписчикам в сеансах агента распространителя или агента слияния. Изменения схемы можно делать только на издателе, и оно подчиняется всем ограничениям для команды ALTER, предписываемым правилами языка Transact­SQL (например, нельзя изменять поля первичного ключа).

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

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

Изменения схемы, тиражируемые подписчикам других СУБД, требуют повторной инициализации. Не поддерживаются изменения схемы для издателей других типов СУБД. Также повторная инициализация потребуется в репликации транзакций после добавления колонки со свойством timestamp.

В SQL Server 2000 вы не могли для изменения набора столбцов статьи использовать команду ALTER TABLE, для этого нужно было использовать системные процедуры sp_repladdcolumn и sp_repldropcolumn. Кроме этого, существовала возможность внести изменения в окне свойств публикации или использовать соответствующие объекты SQL Distributed Management Objects (SQL/DMO).

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

Репликация в SQL Server 2005 может работать более производительно, чем в прежних версиях, с помощью использования возможности динамической фильтрации. Это возможно за счет введения используемых по умолчанию предварительно вычисляемых секций (Precomputed Partitions).

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

Для этого необходимо выполнение нескольких условий. Любые функции, используемые в динамических фильтрах, такие как HOST_NAME() и SUSER_SNAME(), должны использоваться только в условии фильтрации и не могут находиться внутри представления, join­фильтра или пользовательской динамической функции.

Представления, используемые в join­фильтрах, тоже не должны содержать динамические функции. Значение, возвращаемое для каждого подписчика, не должно измениться после того, как раздел был создан. Например, для HOST_NAME() нельзя будет изменить имя сервера подписчика. Условия динамической фильтрации и join­фильтры не могут использовать поля text, ntext или image. И последнее, в публикации с join­фильтром не должно быть замкнутых связей.

Кроме больших нововведений, в SQL Server 2005 появились и не столь значимые, но зато добавляющие удобства в работе функции. Так, например, теперь стала возможной инициализация подписчика репликации транзакций из резервной копии. Повышена производительность синхронизации данных во время сеанса репликации. Более удобным стал монитор репликации. Добавлены предупреждения о проблемах производительности. Можно измерить задержки репликации транзакций по завершению подписчиком начатой на издателе транзакции. Реализовано добавление в сеанс репликации транзакций записей трассировки производительности. Статистика сеанса репликации слиянием углублена до уровня статьи. Можно видеть процент исполнения сеанса агентом репликации слияния. Добавлена процедура, позволяющая корректно менять метаданные репликации после смены имени сервера. Для этого нужно выполнить следующую инструкцию:

EXEC sp_rename_replication_server 'SubscriberA', Ã
'SubscriberB'

Новые, максимальные типы данных для больших значений не имеют присущих текстовым значениям недостатков и ограничений репликации. Такие типы, как varchar(max), nvarchar(max) и varbinary(max) можно применять вместо привычных типов: text, ntext и image. В SQL Server 2008 получила дальнейшее развитие одноранговая репликация транзакций. Появилась возможность автоматического обнаружения конфликтов сеансов репликации, которые отслеживает агент распространителя и это поведение включено по умолчанию. Также в этой версии добавление узлов в топологию репликации не требует остановки репликации по всей топологии до того момента, пока изменения не будут доставлены всем узлам. Для этого был добавлен еще один тип синхронизации init from lsn, который передается в качестве параметра @sync_type системной хранимой процедуры sp_addsubscription. Разумеется, все это возможно сделать и с помощью соответствующего мастера определения топологии одноранговой репликации транзакций. Кстати, этот входящий в состав SQL Server 2008 мастер позволяет управлять топологией одноранговой репликации с помощью визуальных средств.

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

Заключение

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

Список ссылок

•    SQL.RU (http://www.sql.ru/forum/actualtopics.aspx?bid=1).

•    Александр Волок (http://dev.net.ua/blogs/def1983).

•    Ян Либерман (http://blogs.gotdotnet.ru/personal/yliberman).

•    Владислав Щербинин (http://scherbinin.blogspot.com).

•    Александр Гладченко (http://msmvps.com/blogs/gladchenko).

•    Ирина Наумова (http://msmvps.com/blogs/iri­nanau­mova).

*-См. А. Гладченко. Основы репликации SQL Server 2008. Части 1 и 2 // SQL Server для администраторов. 2009. № 12. 2010. № 1.

Секционирование в выпуске SQL Server, отличном от Enterprise Edition

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

Что такое секционирование и зачем его использовать?

Секционирование таблиц позволяет разбить данные на части согласно определенной схеме или ряду правил. Это необходимо главным образом для улучшения производительности запроса: если секционирование применяется и если оно выполнено по правильно подобранной, исходя из характера ваших данных, схеме, то пока вы придерживаетесь правил, определенных в этой схеме, ваши запросы секционированным таблицам не будут сильно нагружать систему за счет того, что они будут затрагивать только нужные таблицы. Впервые эта возможность была представлена в SQL 2005. Представьте себе таблицу в 60 миллионов строк; в зависимости от сложности запроса, количе­ства операций соединения и критериев, опрос такой таблицы может отнять значительное количество времени. При условии же применения секционирования количество запрашиваемых строк уменьшается пропорционально увеличению степени гранулярности схемы.

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

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

Я расскажу вам, как выполнить секционирование таблиц в базе данных SQL Server, не прибегая к средствам выпуска Enterprise Edition; описываемый способ годится для версий SQL Server 2000, 2005 и 2008.

Некоторые примеры использования XML

Передача набора строк в хранимую процедуру

Вам необходимо многократно передавать табличный результат в хранимую процедуру. Несмотря на то, что SQL Server 2000 и SQL Server 2005 имеют тип данных, который называется табличной переменной, вы не можете использовать ее как параметр в хранимых процедурах. Начиная с версии SQL 2000, Microsoft все в большей мере поддерживает XML. Я знаю, что большинство из вас уже использовало XML или, по крайней мере, много слышало о XML; однако я не хочу углуб­ляться в XML, а лишь хочу показать вам варианты его использования. Для тех из вас, кто не знаком с XML, следующая ссылка даст хорошее введение в предмет: www.topxml.com/sql/learn_sql_server_xml_tutorial.asp.

Итак, начнем.

Добавьте специфики в вашу базу данных Model на SQL Server

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

SQL Server устанавливает следующие системные базы данных:

•    Master-Хранит описание всех других баз данных, плюс логины базы данных и собственные системные таблицы.

•    Model-Служит снимком каждой новой базы данных, которую вы создаете.

•    Msdb-Служит для размещения кода и данных, которые поддерживают SQL Server Agent и SQL Server Management Studio (и ранее Enterprise Manager).

•    Tempdb-Всякий раз, когда вы создаете временную таблицу (то есть таблицу, имя которой начинается «#» или «##»), она создается в этой базе данных. Кроме того, SQL Server использует эту базу данных, чтобы размещать в ней свои собственные временные таблицы (например, когда вы используете ORDER BY, SQL Server сортирует результаты именно здесь). Вы модифицируете эту базу данных множество раз в течение часа, и даже минуты.

•    Mssqlresourcedb-Хранит системные объекты. Если вы не заходите с черного хода, эта база данных скрыта и является доступной только для чтения. Это внутренность SQL Server.

Если вы используете репликацию, SQL Server может также установить такую базу данных:

•    Distribution-Хранит информацию об издателях, подписчиках, адресатах сервера и т. д.

Примечание-Вы никогда не должны модифицировать базы данных Master, MSDB и Mssqlresourcedb.

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

Предположим, что вы — независимый консультант, который создает YAFOES (еще одна дружественная система ввода заказов). Специфика может различаться, но вообще­то они все похожи, как копилки: Клиенты, Заказы, Детали, Продукция, Платежи и так далее. Итак, почему бы не добавить эти таблицы в Model?

Мы создали резервную копию для базы модели, после чего создали несколько типовых таблиц в Model, исходя из предположения, что мы — разработчики программ YAFOES.

Примечание-Перед последующими экспериментами настоятельно рекомендуем вам сделать резервную копию Model!

Теперь выполните скрипт в листинге А, чтобы создать несколько простых таблиц в Модели. Также добавим представление, пользовательскую функцию (UDF) и хранимую процедуру, а также описания таблиц и столбцов и одно или два значения по умол­чанию.

Теперь создайте новую базу данных, которая содержит все новые объекты базы данных, точно такие, как мы определили их. По различным причинам, создают отдельные базы данных X, Y и Z (продажи, маркетинг, продукция), однако, все они должны, в конечном счете, приводиться к единому представлению о предприятии, используя SSIS или Cognos или еще что­нибудь на ваш вкус. Мы считаем, что начинать такое согласование нужно в базе данных Model. Как только вы настроите базу данных Model описанным выше способом (с учетом вашей специфики), каждая база данных, которую вы создаете, будет содержать в точности те же самые определения таблиц и столбцов.

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

Эти эксперименты привели к убеждению, что база данных Model является самым пропускаемым в объяснениях и малоиспользуемым объектом SQL Server.

Чем можно заменить строковые индексы? Есть хеширование!

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

Однако вам не обязательно так поступать. Есть очень простая альтернатива, использующая то, что еще известно под названием хэш­блоков или хэш­ключей.

Что такое хэширование?

Говоря коротко, хэширование — это целочисленный результат алгоритма (известного как хэш­функция), применяемого к заданной строке. Вы передаете в алгоритм строку, а на выходе получаете целое число. Если вы используете эффективную хэш­функцию, то вероятность того, что две различных строки дадут одно и то же значение хэш­функции, будет невелика. Такой случай известен под названием коллизии хэширования. Предположим, что вы применили к этой статье алгоритм хэширования, затем изменили один символ в статье и повторили алгоритм: он возвратил бы другое целое число.

Умножение и деление чисел типа NUMERIC

Может быть, вам покажутся удивительными результаты следующих арифметических операций:

declare @num1 numeric(38,10)
declare @num2 numeric(38,10)
set @num1 = .0000006
set @num2 = 1.0
select cast( @num1 * @num2 as numeric(38,10))

Дает: .0000010000

Вместо: .0000006000

Почему? BOL (смотри Precision, Scale и Length) опре­деляет следующие правила для арифметических операций c числами типа NUMERIC (табл. 1).

В нашем случае точность и масштаб умножения вычисляется так:

Точность = P1 + P2 + 1 = 38 + 38 + 1 = 77
Масштаб = S1 + S2 = 10 + 10 = 20

Соответственно, результатом должно быть число типа numeric(77, 20), что не допускается. Вот где нам понадобится сноска:

BOL в настоящий момент не вдается в подробности того, как выполняется усечение.

Поскольку точность превышает 38, мы постараемся избежать усечения целой части значения уменьшением масштаба (вместо этого усекая дробную часть значения). Каким количеством масштаба пожертвовать? Здесь нет правильного ответа. Если оставить слишком много, то будет потерян результат умножения больших чисел. Если оставить слишком мало, умножение малых чисел станет проблемой. В SQL Server 2005 RTM (и предыдущих версиях) мы решили оставить минимальный масштаб — 6 как для умножения, так и деления. Поэтому наше numeric(77,20) усекалось до numeric(38,6), а затем приводилось к numeric(38,10). Однако это было сделано слишком поздно, и некоторые данные были потеряны. Это объясняет результат, который вы можете увидеть выше.

Поэтому важно стараться задавать по минимуму точность и масштаб операндов в умножении и делении. В этом случае:

declare @num1 numeric(18,10)
declare @num2 numeric(18,10)
set @num1 = .0000006
set @num2 = 1.0
select cast( @num1 * @num2 as numeric(38,10))

Тип результата должен быть numeric(37,20). По­скольку точность и масштаб типа не превышает наших текущих пределов, неявное усечение не проводится. Затем мы приводим результат к numeric(38,10), что не вызывает потери данных в нашем случае.

Если вы не можете точно типизировать значения, участвующие в умножении и делении, например, если они являются параметрами процедуры, которая вызывается с большим разбросом значений, возможно, стоит обратить внимание на приближенные числовые типы (float, real) или определить свой собственный «высокоемкий» пользовательский точный числовой тип данных, используя CLR.

Надеемся, что это было полезно для вас. Дайте нам знать, если вы хотите прочитать о чем­то конкретно.

Табл. 1

* Точность и масштаб результата имеет абсолютный максимум 38. Если точность результата превышает 38, соответствующий масштаб уменьшается, чтобы предотвратить усечение целой части результата.

Как обойти отсутствие массивов в SQL Server 2000

Иногда приходится сожалеть о том, что в Transact-SQL Microsoft SQL Server нет такой структуры, как Array (массив). Многие программисты SQL поддержат меня. Массив — одна из наиболее общих и часто используемых структур программирования. Действительно, T-SQL не предусматривает полностью функциональную структуру массива. Однако SQL 2000 ввел новую возможность, называемую переменной табличного типа, которая позволяет имитировать массив и/или использоваться вместо курсора в SQL Server.

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

Я разбил свой подход на три части:

•    Создание массива в хранимых процедурах.

•    Передача и возвращение табличных переменных в/из хранимых процедур.

•    Использование «массива» вместо курсоров.

(Возврат на основную страницу)