Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#222<< #223 |
СОДЕРЖАНИЕ Data Mining & Reporting Services & Особенности реализации учетных задач
Дата: 19.11.2004г. 18:30 1. Особенности реализации учетных задач в условиях существенной динамики бизнес-процессов. Андрей Гордиенко 2. Data Mining - возможности и приёмы использования. Заур Нуралиев Для регистрации на семинар, пришлите письмо в свободной форме на адрес mssqlhelp@rambler.ru, с указанием Вашей фамилии, имени и отчества (полностью). Количество мест в аудитории семинара ограничено, поэтому прошу Вас не откладывать регистрацию. За день до даты проведения семинара, всем кто был успешно зарегистрирован, по электронной почте придёт письмо с подтверждением регистрации. Для того, что бы пройти в помещение проведения семинара, при себе необходимо иметь паспорт или другое удостоверение личности. Карта проезда в представительство Microsoft
Лекции для разработчиков Microsoft .NET С 16 по 26 ноября в городах России (Томск, Новосибирск, Казань, Самара, Ростов) пройдет тур лекций для групп разработчиков Microsoft .NET при поддержке Microsoft Russia и INETA Europe. Участие в семинарах бесплатное. Докладчики:
Встречи будут интересны широкому кругу разработчиков, руководителям проектов, заинтересованных в использовании современных технологий и инструментов Microsoft для создания программного обеспечения. Место и время проведения:
Томск, 16 ноября, вторник. Участие в семинаре бесплатное при предварительной регистрации на страницах групп разработчиков. Следите за дополнительной информацией. Блокировки SQL Server 7.0/2000 - теория и практика устранения проблем (продолжение)
По материалам статьи KB224453
Understanding and Resolving SQL Server 7.0 or 2000 Blocking Problems
Введение Типовые сценарии нахождения и разрешения блокировок Используя приёмы, описанные выше, в большинстве случаев вы можете определить причины проблем, вызванных блокировками. Остальная часть статьи посвящена обсуждению того, как после этого использовать полученную информацию для выявления проблемы и её устранения с помощью типовых сценариев. Подразумевается, что для получения информации о блокировках, Вы используете сценарии, приведенные в статье Q251004 (ссылка дана выше), а также используете описанные выше события для сбора информации с помощью профайлера. Обзор результатов типовых сценариев поиска блокировок.
Анализ данных, полученных с помощью профайлера
Изучение данных профайлера может повысить эффективность решения проблем с блокированием. Не понадобится собирать
лишнюю информацию, и профайлер предоставляет возможности для более эффективного сбора данных. В диалоговом окне
Properties (Меню FILE -->Properties), профайлер позволяет ограничить количество получаемых данных путем исключения
лишних столбцов данных или событий, группировать данные и применять к ним фильтры. Вы можете осуществлять поиск по
всей трассе или искать определенные значения определенного столбца данных. (Меню Edit-' Find). Также имеется
возможность сохранять трассу в таблицу SQL Server (Меню File -' Save As -' Table). Что искать:
ПРОДОЛЖЕНИЕ СЛЕДУЕТ За и против использования команды SELECT, представлений и хранимых процедур в SQL Server (окончание)
По материалам статьи G. Vijayakumar
Pros & Cons of Using SELECT, Views, and Stored Procedures in SQL Server Хранимые процедуры Мы создадим хранимую процедуру с одним параметром и посмотрим, чем она отличается от команды SELECT и представления. CREATE PROC spDummyTable1 (@EmpID Int) AS SELECT EmpID, EmpName FROM DummyTable1 WHERE EmpID = @EmpID Теперь давайте выполним следующие команды, чтобы увидеть данные и информацию из кэша для хранимой процедуры spDummyTable1. EXEC spDummyTable1 1 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
SQL Server отображает скомпилированный и выполненный планы для хранимой процедуры spDummyTable1. Давайте снова выполним ту же команду и посмотрим информацию в кэше. EXEC spDummyTable1 1 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Значение Usecounts увеличилось. SQL Server использовал тот же скомпилированный план для команды SELECT и увеличил значение Usecounts выполненного плана. Один и тот же скомпилированный план будет использоваться все время, пока будет выполняться одна и та же хранимая процедура. Давайте выполним ту же хранимую процедуру с другим значением параметра empid и взглянем на информацию в кэше. EXEC spDummyTable1 3 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Значение Usecounts увеличилось. Хотя мы задали другое значение empid, SQL Server использовал тот же скомпилированный план для хранимой процедуры и увеличил значение Usecounts выполненного плана. Теперь давайте выполним эту же хранимую процедуру с указанием владельца и взглянем на информацию в кэше. EXEC dbo.spDummyTable1 5 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Никаких изменений. SQL Server использовал тот же скомпилированный план для хранимой процедуры и увеличил значение Usecounts выполненного плана. Давайте выполним эту же хранимую процедуру другим пользователем. Я создал нового пользователя, 'user1', и дал ему права на выполнение хранимой процедуры spDummyTable1. Я открыл другой Query Analyzer и подсоединился, используя UID: user1; PWD : user1. После этого я выполнил следующую команду. EXEC dbo.spDummyTable1 3 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO Разные пользователи, выполняя хранимую процедуру с разным или одинаковым значением empid, используют тот же скомпилированный план и увеличивают значение Usecounts выполненного плана. Теперь давайте выполним эту же хранимую процедуру с указанием базы данных и владельца и взглянем на информацию в кэше. EXEC vijay.dbo.spDummyTable1 7 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Никаких изменений. SQL Server использовал тот же скомпилированный план для хранимой процедуры и увеличил значение Usecounts выполненного плана. В результате можно сделать вывод, что хранимая процедура компилируется один раз, использует один и тот же скомпилированный план и увеличивает значение Usecounts выполненного плана. Хранимая процедура уже предварительно загружена в память для быстрого выполнения, что повышает производительность системы. Это действительно показывает нам важность хранимой процедуры по сравнению с командой SELECT и представлением. Теперь давайте выполним следующую команду для очистки кэша перед экспериментированием с представлениями. DBCC FREEPROCCACHE GO Представления Мы создадим представление и посмотрим, чем оно отличается от команды SELECT и хранимой процедуры. CREATE VIEW vwDummyTable1 AS SELECT EmpID, EmpName FROM DummyTable1 GO Теперь давайте выполним следующие команды для отображения данных и информации в кэше для созданного представления vwDummyTable1. SELECT EmpId, EmpName from vwDummyTable1 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
SQL Server показывает скомпилированный план и выполненный план для представления vwDummyTable1. Теперь давайте снова выполним ту же команду и взглянем на информацию в кэше. SELECT EmpId, EmpName from vwDummyTable1 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Значение Usecounts увеличилось. SQL Server использовал тот же скомпилированный план для команды SELECT представления и увеличил значение Usecounts выполненного плана. Один и тот же скомпилированный план будет использоваться все время, пока мы будем выполнять ту же команду SELECT представления. Теперь давайте добавим выражение WHERE в команду SELECT представления и взглянем на результаты в таблице master.dbo.Syscacheobjects. SELECT EmpId, EmpName from vwDummyTable1 WHERE EmpID = 4 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO SQL Server не использовал существующий план в кэше из-за изменения команды SELECT представления. SQL Server сгененировал новый план кэша для команды SELECT представления, оставив там и старый план.
Давайте выполним ту же команду SELECT представления с другим empid и взглянем на результаты. SELECT EmpId, EmpName FROM vwDummyTable1 WHERE EmpID = 8 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Хотя мы задали другое значение empid, SQL Server использовал тот же скомпилированный план для команды SELECT представления и увеличил значение Usecounts выполненного плана. Разные пользователи могут выполнять команду SELECT представления с разными значениями empid, при этом будет использоваться тот же скомпилированный план и будет увеличиваться значение Usecounts выполненного плана. Теперь давайте выполним ту же команду представления с указанием владельца в SELECT и взглянем на результаты. SELECT EmpId, EmpName from dbo.vwDummyTable1 WHERE EmpID = 8 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Теперь мы получили еще 2 строки в кэше, потому что использовали разные имена владельцев в команде SELECT. SQL Server генерирует новый скомпилированный план и выполненный план для другого пользователя. Если этот пользователь выполнит команду SELECT больше одного раза, то будет использован этот же скомпилированный план и будет увеличено значение Usecounts выполненного плана. Давайте выполним ту же команду SELECT представления с другим empid и проверим результат. SELECT EmpId, EmpName from dbo.vwDummyTable1 WHERE EmpID = 6 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Теперь давайте выполним ту же команду с указанием базы данных и владельца в команде SELECT представления и проверим результат. SELECT EmpId, EmpName from vijay.dbo.vwDummyTable1 WHERE EmpID = 10 GO SELECT cacheobjtype, refcounts, usecounts, sql FROM master.dbo.Syscacheobjects GO
Мы увидели, что можем минимизировать создание скомпилированных планов, если добавим имя базы данных, владельца и выражение WHERE в команду SELECT или в представление. Если вы измените что-либо из этого, то ваш код придется перекомпилировать, что уменьшит производительность системы. Так какая же разница между командой SELECT и представлением относительно производительности? Есть ли вообще между ними разница? Нет, скомпилированный план и выполненный план одинаковы и для команды SELECT, и для представления. Есть только одно различие - представление физически хранится в базе данных, а команда SELECT - нет. Преимуществом представлений является более легкое администрирование прав доступа к объектам. Например, вы создаете представление и даете права на выполнение команды SELECT определенному набору пользователей, что дает право этим пользователям видеть только определенные столбцы в таблице, а не все. В большинстве случаев, если вам не нужно обеспечивать с помощью представлений дополнительную безопасность, то в использовании представлений нет необходимости. Биография G. Vijayakumar имеет опыт работы с клиент-серверными и web-приложениями. В настоящее время он работает в Transworld (Бангалор, Индия) и занимается e-banking продуктами. Статьи на русском языке
Параллельные планы выполнения SQL Server
Basics of C2 Auditing Самые популярные темы недели
Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
T-SQL и создать в общих папку на MS Exchange 5.5
|
#222<< #223 |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||