SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |
   
#219<<  #220  >>#221

СОДЕРЖАНИЕ

1.КОНФЕРЕНЦИЯ
1.1.ПЛАТФОРМА 2005
2.СОВЕТЫ
2.1.Параллельные планы выполнения SQL Server
3.ССЫЛКИ НА СТАТЬИ
3.1.Статьи на русском языке
3.2.Англоязычные статьи
4.ФОРУМ SQL.RU
4.1.Самые популярные темы недели
4.2.Вопросы остались без ответа
5.ПОЛЕЗНОСТИ
5.1.Методы и модели анализа данных: OLAP и Data Mining

КОНФЕРЕНЦИЯ

Определяя
будущее

приглашаем вас на шестую ежегодную конференцию

1200 участников

Более 1200 участников — специалистов в области информационных технологий промышленных предприятий, государственных структур, банков и корпораций России и стран СНГ.

45 докладов

Более 45 технических докладов, подготовленных ведущими специалистами Microsoft. Несколько докладов будут посвящены SQL Server, среди докладчиков представители Russian SQL Server Club, который существует в рамках пректа SQL.RU

Практика

Практические занятия по продуктам и технологиям Microsoft.

Выставка

Выставка решений партнеров Microsoft в области построения ИТ-структуры предприятий различного уровня.

Обмен опытом

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

Два насыщенных дня

Конференция «Платформа 2005» пройдет 1—2 декабря 2004 года в Москве.

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

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

Темы докладов

Участие в семинаре платное.

Стоимость участия (2 дня):

  • 3000 рублей (НДС включен) — если вы оплачиваете свое участие до 1 ноября включительно.
  • 4000 рублей (НДС включен) — если вы оплачиваете свое участие после 1 ноября.

В стоимость включено:

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

Зарегистрируйтесь

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

По вопросам регистрации

в Информационном центре Microsoft по телефонам:
Москва — (095) 916-71-10;
бесплатный звонок из городов России — 8 800 200-80-01;
для звонков из Украины — +38 044 230-51-01;
для звонков из Казахстана — (3272) 98-01-26.

По вопросам оплаты участия

в агентстве ARS-Communications — официальном партнере Microsoft по организации конференции — по телефонам: (095) 782-04-73, 782-04-95.

Следите за обновлениями. В ближайшее время будет опубликована более подробная информация о конференции.

[В начало]

СОВЕТЫ

Параллельные планы выполнения SQL Server

По материалам статьи Joe Chang SQL Server Parallel Execution Plans
Перевод Виталия Степаненко

Microsoft SQL Server представил возможность параллельной обработки запросов в версии 7.0. Целью параллельного выполнения запроса является более быстрое выполнение запроса, использующего большое количество данных, на многопроцессорном компьютере, чем это возможно при помощи одного потока. Books Online и различные документы Microsoft описывают принципы параллельного выполнения и использование настроек, влияющих на параллельное выполнение. Однако очень мало влияния уделяется объяснению планов выполнения с использованием параллелизма. Сравнение нескольких запросов с параллельными планами выполнения с планом выполнения, когда параллельность отключена, обеспечивает понимание некоторых характеристик параллельных планов выполнения, включая значения оценочных затрат. Рассмотрение запросов с использованием и без использования параллельных планов выполнения дает дополнительную информацию о случаях, когда параллельное выполнение более предпочтительно, и когда его нужно отключать.

Параллельная обработка запроса

Рис.1 ниже показывает часть планов выполнения для запроса с использованием и без использования параллельных операций. Запрос - это простой SELECT с поисковым аргументом WHERE (SARG), агрегатами в списке SELECT, и выражением GROUP BY. Для непараллельного плана выполнения задано выражение OPTION (MAXDOP 1).

Рис.1. Непараллельные и параллельные части плана выполнения.

Заметим, что символы обычных операций SQL - таких, как Index Seek, Hash Match, и Compute Scalar - имеют желтый круг со стрелками в нижнем правом углу, в случае, когда в этом операции используется параллельное выполнение. Символ Parallelism/Gather Streams на рис.1 является специфическим для параллельных планов выполнения. Другими специфическими для параллельных планов выполнения символами являются Parallelism/Broadcast, Parallelism/Distribute Streams и Parallelism Repartition Streams.

Рис.2 ниже показывает левую часть двух планов выполнения из рис.1. Верхний запрос с относительными по отношению к пакету (запрос 1 и запрос 2) затратами в 66.65% - это непараллельный план выполнения, а нижний запрос с затратами в 33.35% - это параллельный план выполнения.

Рис.2. Относительные затраты непараллельного (вверху) и параллельного (внизу) планов выполнения.

Рис.3 ниже показывает окна детализации для символов SELECT непараллельного (слева) и параллельного (справа) планов выполнения. Непараллельный план выполнения имеет общие оценочные затраты в 121, а параллельный план - 60.7, из которых получаются относительные затраты в 66.65% и 33.35% на рис.2.

Рис.3. Окна детализации непараллельного (слева) и параллельного (справа) планов выполнения.

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

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

Рис.4а. Окно детализации непараллельного поиска по кластерному индексу.

Рис.4b. Окно детализации параллельного поиска по кластерному индексу.

Тот же случай наблюдается и для непараллельных и параллельных операций Hash Match/Aggregate, как показано на рис.4c и 4d.

Рис.4с. Окно детализации непараллельного выполнения операции Hash Match/Aggregate.

Рис.4d. Окно детализации параллельного выполнения операции Hash Match/Aggregate.

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

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

Рис.5 ниже показывает часть параллельного плана выполнения для другого запроса. Рис.6а показывает окно детализации непараллельного плана выполнения для сканирования кластерного индекса таблицы Customer, а рис.6b показывает окно детализации параллельного плана выполнения для сканирования кластерного индекса таблицы Customer.

Рис.5. Параллельный план выполнения для второго примера.

Рис.6а. Окно детализации непараллельного сканирования кластерного индекса.

Рис.6b. Окно детализации параллельного сканирования кластерного индекса.

Непараллельную версию достаточно легче объяснить. Оценочные затраты ввода-вывода равны 2.45, а загрузка процессора равна 0.165 из общих затрат в 2.61, хотя сумма цифр и не равна в точности общим затратам. Параллельную версию объяснить сложнее. Затраты ввода-вывода составляют примерно половину непараллельных затрат ввода-вывода, а загрузка процессора - только одну четверть, но общие затраты параллельного плана в 2.529 ненамного меньше общих затрат непараллельного плана, равных 2.651.

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

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

Рис.7 показывает другой аспект параллельных планов выполнения. Таблица Nation в верхнем правом углу небольшая и сканируется при помощи непараллельной операции. Результаты сканирования распределены по нескольким потокам операцией Parallelism/Distribute Streams.

Рис.7. Параллельный план выполнения с непараллельным компонентом.

Анализ запроса TPC-H в SQL Server

Простым методом исследования параллельных планов выполнения является использование данных и генераторов кода из теста TPC-H. Transaction Processing Council (tpc.org) поставляет исходный код для программы dgen, используемой для создания набора данных для теста TPC-H и программы qgen для создания запросов. Большинство недавно опубликованных тестов TPC-H используют наборы данных в 100 гигабайт как минимум и гораздо большие. Однако даже набор данных размером в 1 гигабайт подходит для создания параллельных планов выполнения в SQL Server. Если набор данных достаточно маленький, чтобы полностью размещаться в памяти, то при этом дисковая система не становится узким местом, что позволяет для простых тестовых конфигураций сосредоточиться на исследовании загрузки процессора.

Табл.1 ниже показывает оценочные затраты плана выполнения для 22 запросов TPC-H с гигабайтной (только данные) таблицей LineItem, содержащей 6 миллионов строк. В этом случае 18 из 22 запросов сгенерировали параллельный план выполнения. В некоторых случаях (запросы 1 и 6) затраты параллельного плана выполнения составляют примерно половину затрат непараллельного плана. В большинстве случаев параллельный план получается несколько менее затратным, чем непараллельный план, но не на 50%. В одном случае, в запросе 5, параллельный план более затратный, чем непараллельный, несмотря даже на то, что план выполнения по умолчанию (без хинтов) параллельный.

Query

Non-Parallel

Parallel Plan

1

121.3

60.7

2

5.0

N/A

3

111.8

77.0

4

109.0

103.8

5

132.3

145.6

6

15.8

7.9

7

72.2

65.7

8

138.3

N/A

9

199.3

N/A

10

112.1

107.8

11

33.9

N/A

12

136.1

127.9

13

32.4

29.5

14

6.4

6.0

15

5.2

4.0

16

19.5

17.5

17

20.5

20.3

18

177.8

152.0

19

48.5

47.7

20

24.8

20.7

21

367.6

360.6

22

15.8

15.7

Табл.1. Затраты плана выполнения для запросов TPC-H на гигабайтном наборе данных LineItem.

Табл.2 показывает лучшие измеренные значения времени выполнения для SQL Server 2000 и Windows Server 2003 на сервере с двумя процессорами Xeon 2.4 Гц с включенной технологией Hyper-Threading (HT) и с 2 гигабайтами памяти. Каждый запрос был последовательно запущен несколько раз, чтобы набор данных хранился в памяти, что можно определить по минимальной активности диска. Лучшее время из нескольких последовательных выполнений запроса выбирается, чтобы исключить оптимизированные затраты на выполнение запроса, которые сами по себе являются очень интересным предметом исследования. Есть случайные вариации продолжительности времени выполнения, даже между вторым, третьим и четвертым выполнениями. Продолжительность времени выполнения была отслежена в SQL Profiler вместе с загрузкой процессора и уровнем параллелизма (DOP), который определяет количество используемых потоков.

Query

DOP 1

DOP 2

DOP 4 (HT)

1

20,703

12,686

13,563

2

126

N/A

N/A

3

3,153

2,686

3,016

4

4,140

2,983

2,610

5

4,423

3,796

9,953

6

546

343

373

7

4,110

2,486

3,060

8

3,376

N/A

N/A

9

11,500

N/A

N/A

10

2,610

2,250

2,080

11

876

N/A

N/A

12

3,516

2,733

2,410

13

9,343

7,813

5,436

14

436

516

576

15

390

610

783

16

3,173

2,390

2,470

17

203

373

716

18

11,720

7,860

7,516

19

560

360

406

20

453

1,280

1,470

21

14,500

9,486

9,250

22

2,373

1,420

2,440

Табл.2. Лучшее измеренное время (мс) на гигабайтном наборе данных.

Когда DOP равен 2, то похоже, что операционная система или SQL Server знают, что нужно использовать два разных физических процессора, а не два логических процессора на одном физическом процессоре. Возможно, что это достигается полностью при помощи упорядочивания физических и логических процессоров. При DOP, равном 4, есть только 2 физических процессора, поэтому это не является тестированием способности SQL Server производить параллельное выполнение на 4 физических процессорах, а скорее является тестированием преимущества HT в параллельных планах выполнения.

Синий шрифт в столбце DOP 2 показывает случаи, когда время выполнения запроса уменьшалось более чем на 30%. В целом 7 из 18 запросов с параллельным планом выполнения показали уменьшение времени более чем на 30% при 4 запросах, которые оказались медленнее. Суммарное время выполнения для всех 18 запросов с параллельными планами выполнения оказалось 29% меньше, чем для тех же 18 запросов без параллельных планов выполнения. Запросы, которые оказались медленнее, не были предсказаны как более медленные планом выполнения, а запросы, которые были предсказаны как более медленные, оказались на самом деле быстрее при использовании параллельного выполнения. Похоже, что параллельное выполнение сканирования таблицы и индекса значительно уменьшает время выполнения, несмотря на то, что оценочные затраты плана выполнения этого никак не отражают.

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

В пяти запросах параллельное выполнение на всех логических процессорах обеспечивает дальнейшее улучшение производительности, но в пяти других запросах использование дополнительных логических процессоров ухудшает производительность по сравнению с непараллельным или параллельным выполнением с двумя физическими процессорами. Hyper-threading - это потенциально очень полезная особенность. Однако ее не следует использовать вслепую. К счастью, Microsoft очень тщательно исследует использование HT в Yukon и разработает подходящие алгоритмы для определения, когда HT нужно использовать, а когда - нет.

Заключение

Исследование планов выполнения для набора запросов определенно предполагает, что единицей измерения в затратах плана выполнения является время, а не загрузка процессора. Поэтому параллельный план выполнения может показывать более низкие затраты, чем непараллельный план. Более того, SQL Server оценивает параллельное выполнение определенных операций, таких, как поиск по индексу и hash match, в 2 раза быстрее с двумя потоками по сравнению с одним потоком. По некоторым причинам SQL Server не показывает для сканирования таблицы и индекса ощутимого преимущества от параллельного выполнения, несмотря даже на то, что действительная оценка параллельного выполнения запроса показывает такое преимущество.

Параллельные планы выполнения требуют дополнительных операций, из-за которых дополнительные затраты могут свести на нет преимущества параллельного плана выполнения, но это нужно определить выполнением тестов. Не было определено, какую единицу времени отражают затраты плана выполнения. Разумным предположением может быть то, что затраты плана выполнения измеряются в секундах процессора, который был обычным во время разработки SQL Server 7.0. Это могло быть что угодно от Pentium 100MHz до Pentium Pro 200MHz. Возможно, что реальное время выполнения было в среднем в 20 раз быстрее на системах с процессором Xeon 2.4 Гц, чем отражалось в затратах плана выполнения, если единица измерения является секундой.

[В начало]

ССЫЛКИ НА СТАТЬИ

Статьи на русском языке

Операции с большими объемами данных в SQL Server
Joe Chang
В статьях серии Анализ производительности рассматривались формулы внутренних затрат ресурсов, использующиеся в оптимизаторе запросов SQL Server для определения плана выполнения и сами затраты ресурсов на выполнение запросов для конфигураций с данными в памяти. Предыдущие статьи ограничились анализом затрат ресурсов на выполнение запросов для случаев, когда все нужные данные находятся в памяти, так что производительность не ограничивалась конфигурацией диска. Эта статья дает представление о запросах, работающим с объемом данных, большим, чем доступная память, и запросах, выполняющих операции записи, где производительность ограничена конфигурацией диска
Первый взгляд на затраты плана выполнения в Yukon Beta 1
Joe Chang
Многих из нас интересуют изменения в Yukon и его особенности. С первого взгляда можно заметить некоторые отличия в формулах затрат плана выполнения в Yukon Beta 1. Скорее всего, еще больше изменений будет сделано между Beta 1 и финальной версией...

[В начало]

Англоязычные статьи

SQL Server 2000 Incremental Bulk Load Case Study
Incremental bulk load refers to loading data into a nonempty table. The key question during incremental bulk load is whether indexes should be dropped before bulk load. The answer depends on multiple factors. This paper attempts to answer this question through a case study of incremental bulk load using the BULK INSERT statement on a representative decision support system (DSS) running Microsoft® SQL Server™ 2000 on Microsoft Windows 2003 Server. You should view the results presented in this paper as recommendations instead of absolute answers, because your results will depend on your hardware (for example, number of CPUs, I/O, and network bandwidth), data distribution in the table, and the data files and parameters supported by the BULK INSERT statement. All tests were conducted on a Hewlett-Packard hardware system (for more information about the test environments, see Appendix A, "Test Environments")
Batching DML Operations in SQL Server
extremeexperts.com
This requirement again comes from the repeated posts in the local usergroup of mine. Bussiness processes at some time would want to Update millions of rows based on some criteria. Even for a matter of fact sometimes we would be interested in deleting tons of rows. And issuing a DELETE statement doesnot help as it consumes lots of time. Find below an unique and interesting implementation for the problem in hand. Our moto is to perform the operation fast and efficient way and by reducing the amount of size increase of our transaction log too
DTS: Copy Objects Task
Bruce Szabo
Microsoft has provided so many great tools and at times they have helped solve many issues. There are cases though where the tools do not behave exactly as one would expect. There is nothing more frustrating than finding a tool that is supposed to help, actually causing an error or behaving correctly but in an unexpected manner. This article explores a real world case where the DTS Copy SQL objects task caused me hardship while trying to solve a problem
Architecting Disconnected Mobile Applications Using a Service Oriented Architecture
Arif Kureshy
Mobile devices, such as the Windows Mobile™-based Pocket PCs, have grown significantly popular over the last several years. In the car, on a plane, or out in the middle of nowhere, applications on the device can operate without a connection to any other computers, the Internet, or intranet. Devices can then partner with a desktop computer system by means of a modem, network card, or simply by placing the mobile device in a cradle. New or modified data on either the device or desktop computer system is then automatically migrated and synchronized
The Simplest SQL Notification Application: Stock Quotes
Shyam Pather
This chapter by Shyam Pather introduces you to the basics of SQL-NS and shows you how coding in this environment works
Inside SQL Server 2005 Security
Kalen Delaney
Recently, I've been discussing security in SQL Server 2000. In my February column, "Crossing the Line: Ownership Chains" (InstantDoc ID 40963), I talked about the limitations of ownership chaining and the additional security concerns inherent in cross-database ownership chaining. In my April column, "Object Ownership and Security" (InstantDoc ID 41773), I talked about the confusions and limitations surrounding SQL Server 2000's model, which doesn't separate the concepts of user and schema. This month, let's look at some security enhancements in SQL Server 2005, formerly code-named Yukon, that address these security limitations
XML Best Practices for Microsoft SQL Server 2005
Shankar Pal, Vishesh Parikh, Vasili Zolotov, Leo Giakoumakis, Michael Rys
Microsoft SQL Server 2005 provides extensive support for XML data processing. XML values can be stored natively in an XML data type column, which can be typed according to a collection of XML schemas, or left untyped. You can index the XML column. Furthermore, fine-grained data manipulation is supported using XQuery and XML DML, the latter being an extension for data modification
Performance Optimizations for the XML Data Type
Shankar Pal, Vasili Zolotov, and Leo Giakoumakis
This paper covers several ideas, which are designed to improve query and data modification performance of the XML data type in the upcoming version of Microsoft SQL Server 2005. To get the most value from this paper, you need familiarity with the XML features in SQL Server 2005; see the MSDN article XML Support in Microsoft SQL Server 2005 for background material. (16 printed pages)
Customized Output Labels
Leo Peysakhovich
Last month I had an interesting task to deal with. It had to do with the way our business views the data. In many cases my company is using MS Access as the way to access the data from tables and then save user filtered, ordered, or grouped reports in various formats. I am not saying it is good or bad. It is as it is. In many cases we are using stored procedures to get data out to Access. Stored procedures are linked in ICT Access files. Sometime views are created and linked to Access ICT file as well
Have It Your Way: Conformed Dimensions and Alternate Hierarchies
Bill Lewis
Developing a set of shared, conformed dimensions is a challenge faced by any organization attempting to evolve an enterprise data warehouse environment from a collection of disparate data marts. Computer technologies can be both enablers and inhibiters to such an effort, but the fundamental issue is actually one of corporate diplomacy: how to reconcile the needs of the many — the enterprise as a whole — with the needs of the few — the individual, semi-autonomous business units
Mop the Floor and Fix the Leak, Part 1
Joe Celko
At the end of August, there was an interesting posting on a newsgroup that probably reflects the thinking of a lot of bad SQL programmers. The poster was asked about some basic data integrity issue and in the discussion, he replied that all the validation would be done in the front end application program, so we did not have to bother with constraints on the server side
T-SQL Debugger
Gregory A. Larsen
What method do you use to debug your stored procedures? Do you place a number of PRINT and/or SELECT statements in your stored procedure code to help you trace down why your stored procedures do not work? Did you know that SQL Server provides a T-SQL tool for debugging your stored procedures? The tool is called the T-SQL Debugger. In this article I will discuss how you can use the T-SQL Debugger to determine what it is your stored procedures are doing
Embedded Database Primer
James F. Koopmann
If you’re anything like me, staying on top of current trends within the field of database administration is highly challenging at times. We are continually bombarded with new trends and technology that we cannot normally afford to try. For quite awhile, I have wondered what embedded databases were all about. I think of embedded databases as something small and contained in my cellular phone or as maintaining some information within my automobile. But what is the embedded database world really like?
Duplicate Key Inserted Error During Replication
Andy Warren
If you've set up replication without immediately updating (or even queued updating in SQL2K) subscribers, you may see this error if you allow write access to tables on the subscriber. If a user inserts a record into the subscriber, then later that same key is generated on the publisher, this error will result. Not granting insert permissions on the subscriber is a great way to stop this ---- if your situation allows!
10 Ways to Optimize SQL Server Full-text Indexing
Hilary Cotter
In this article, Hilary Cotter shows you techniques you can use to make SQL Server's full-text indexing, or FTI, work better and faster. Also see his previous article on optimizing full-text searching in the January 2004 issue
Maximum number of database users and roles that you can create
This article provides information about the maximum number of users and roles that you can create in SQL Server 7.0 and SQL Server 2000 databases. You can create a maximum of 16379 security accounts for a database. The maximum number of roles that you can create for a database is 16367
Replication Between Adaptive Server Enterprise and Microsoft SQL Server
Sybase, Inc.
This white paper describes how to configure replication from Adaptive Server Enterprise (ASE) to Microsoft SQL Server (MS SQL Server), and from MS SQL Server to ASE
Custom String Functions
Chris Cathers
When I got done reading Stephen Lasham's article Extracting a String Within Delimiters - Part 2, I thought that I would share with the community, some functions I had just written a couple weeks earlier. I have found that I do a lot of string parsing where I work. It turns out that I am always either reading flat files into SQL, or having to parse some table a Web Developers populates with delaminated strings. As such, I happen to have two functions I've written that I think you may find interesting
Query Notifications in ADO.NET 2.0
Bob Beauchemin
Any non-trivial relational database application is bound to have a lot of lookup tables. If you code graphical user interfaces as a specialty, you know these as the lists that populate the drop-down list boxes. I categorize lookup tables into two types: read-only tables and read-mostly tables. The difference is what can cause those tables to change. I think of a table as read-only if it takes a staff meeting or user meeting to change them. A good example is a table that contains categories of a company's products. That table is not going to change unless the company launches a new product or the company is reorganized. Read-mostly tables are lists that are relatively constant, but can be changed by end users. These usually are presented in combo boxes rather than drop-down lists. An example of a read-mostly table would be a term-of-greeting table. Your application designers can always think of the most common ones, like Ms., Mr., Mrs., and Dr., but there's always the user who has a title you've never thought of and wants to add it in. As an example of how common this is, the last medium-sized product I worked on had a nice third normal form relational database that contained 350-400 tables. I'd estimate that about 250 were read-only or read-mostly tables
How do I know which version of SQL Server I'm running?
aspfaq
For SQL Server 7.0, 2000, and 2005, the following will extract ONLY the version information. This has not been tested with SQL Server 6.5 (sorry, can't find any of those anymore) but works from 7.0 through 2000 (8.0) SP3a and hotfix builds as late as 8.00.952.
SQL Server pros aren't charmed by open source
Robert Westervelt
They are curious about the growing number of open source database products on the market, but some SQL Server DBAs say they remain doubtful that companies will adopt it for the long haul
Microsoft Previewing SQL Server
Clint Boulton
Trolling for as much feedback as possible as it moves toward its next major database release for 2005, Microsoft (Quote, Chart) Friday kicked off a Community Technical Preview (CTP) of SQL Server 2005
Implementing a Flexible Backup Strategy
Eli Leiba
This article describes how to implement a flexible backup strategy for all databases in a given SQL server. All databases are backed up completely or differentially by using a backup strategy control character depending on the database name and the day in the week. The control character will state a "C" for a complete backup or a "D" for a differential backup
SQL Server 2000 Security - Part 13 - SQL Injection attack
Marcin Policht
In articles of this series, we have been so far providing recommendations regarding security-related configuration settings of SQL Server 2000 from the point of view of a database administrator. We have presented a set of guidelines that apply to any generic installation of SQL Server and can be relatively easily configured on the server, database, or database object level. However, typically, access to data is provided via client applications, which increases the range of potential vulnerabilities and places an equal share of responsibility for data security on software developers. This is especially important since application flaws can have just as catastrophic implications as a misconfigured or unsecured SQL Server installation. At the same time, they cannot typically be mitigated by applying hotfixes or patches (as a matter of fact, other database management systems are also vulnerable to this type of attack), but instead, require adherence to specific programming rules. In this article, we will discuss one of the most common application-based SQL Server attacks known as SQL Injection and explain how it can be prevented
MSSQL Server 2000 Reporting Services: Reporting Services Basics: Create a Reusable Template Report
William Pearson
In this article, we will venture away from the functionally specific focuses of recent sessions, and concentrate on a basic consideration that can save us a great deal of time in our work within reporting services. As most of us who have worked with enterprise reporting packages have come to realize, report templates can offer us many advantages in creating reports to meet the needs of information consumers
Creating Triggers Using Managed Code in SQL Server 2005
Thiru Thangarathinam
One of the excellent features provided by SQL Server 2005 (code named Yukon) is its integration with the .NET CLR which makes it possible for us to author triggers, stored procedures, user defined functions, and create other database objects using a managed language such as VB.NET, C#, and so on. This approach provides a number of benefits such as increased productivity, significant performance gains and the ability to leverage the features of .NET Code Access Security to prevent assemblies from performing certain operations and so on. In this article, we will take a look at this new CLR integration feature and learn how to create triggers in SQL Server using a managed language. Along the way, we will also learn how the features of .NET code access security can be leveraged to better control the assembly execution environment. Finally, we will discuss when to use T-SQL and when to use a .NET language when creating SQL Server triggers

[В начало]

ФОРУМ SQL.RU

Самые популярные темы недели

Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
Кто на чем пишет клиентов под SQL Server?
Tool Вы знаете что твориться на ваших 10-30+ серверах ?
Шаманство при Paralellism в процедурах.
Методы авторизации в больших системах
StoredProcedure и SAP R/3
Импорт таблиц из одной БД в другую. Help!
СЕМИНАР: Репликация & Особенности разработки приложений
Книга по Reporting Service
Создание отчётов (PDF или DOC) и рассылка их по e-mail средствами MSSQL, возможно ?
Трабл c запросом....
ПОМОГИТЕ!!! ГОРИМ!!! Чистятся данные базы!!!
Эксператам DTS ... Нужен совет...
Разделение прав администратора и программиста БД
постоянно идет блокировка типа COMPILE???
вопрос о системах со многими пользователями
Как автоматом раставить индексы в запр. по плану запр.?Как заставить выпол. один план зап
Как написать хранимую процедуру
Блок распределенной транзакции.
showplan_text again :)

[В начало]

Вопросы остались без ответа

SQL Formater для MS SQL Server
Дельта структур БД
Использование штрих сканера в учете ...
Каr настроить counter logs через API?
Пару слов о SpotLight for SQL Server: ваше мнение
Что за ошибка?

[В начало]

ПОЛЕЗНОСТИ

Методы и модели анализа данных: OLAP и Data Mining (+ CD-ROM)

А.А. Барсегян, М.С. Куприянов, В.В. Степаненко, И.И. Холод

Издательство: БХВ-Петербург, 2004 г., Твердый переплет, 336 стр., ISBN 5-94157-522-Х, Тираж: 2500 экз., Формат: 70x100/16

В книге представлены наиболее актуальные направления в области разработки корпоративных систем: организация хранилищ данных, оперативный (OLAP) и интеллектуальный анализ данных (Data Mining). Все три направления рассмотрены в достаточном для понимания и дальнейшего использования на практике объеме. Описание методов и алгоритмов анализа данных и иллюстрация их работы на примерах позволит использовать книгу не только как учебное пособие, но и как практическое руководство при разработке программного обеспечения.

[В начало]

#219<<  #220  >>#221
Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013