СОДЕРЖАНИЕ

1. СЕМИНАР 1.1. SQL Server Analisys Services 2. СОВЕТЫ 2.1. Первый взгляд на затраты плана выполнения в Yukon Beta 1 3. ССЫЛКИ НА СТАТЬИ 3.1. Англоязычные статьи 4. ФОРУМ SQL.RU 4.1. Самые популярные темы недели 4.2. Вопросы остались без ответа 5. ПОЛЕЗНОСТИ 5.1. Microsoft SQL Server 2000. Справочник администратора

СЕМИНАР

SQL Server Analisys Services

Санкт-Петербург. 22 октября 2004 года 18:00 в помещении компании DataArt состоится очередной семинар Russian SQL Server Club (Microsoft & SQL.RU).

Встреча проводится при поддержке компаний DataArt и Digital Design.

Для участия в семинаре требуется регистрация: Форма регистрации на семинар

Программа встречи:

1. SQL Server 2000 Analysis Services 2000: Многомерная модель данных. Язык запросов к многомерным данным MDX.  Полина Трофимова, Digital Design

Базовые знания аудитории: Основы SQL.
Будучи открытым стандартом, MDX является основным инструментом программирования для Microsoft SQL Server 2000 Analysis Services. Учитывая актуальность аналитических приложений в современном бизнесе, знание MDX позволяет значительно упростить их разработку на всех этапах производственного цикла начиная с постановки задачи, так как этот язык специально создавался для указанной предметной области и оперирует привычными для аналитика категориями.

2. Реализация системы поддержки принятия решений на основе SQL Server 2000 Analysis Services .  Полина Трофимова, Digital Design


Обзор архитектуры системы, методов реализации модулей управления погрузками данных в Хранилище, обновления моделей данных, демонстрация средства погрузки неструктурированных данных из Excel таблиц, а также средства анализа данных

Информация о месте проведения: DataArt, Санкт-Петербург, Большой Сампсониевский пр., д. 60 А
т. +7 812 333-4440

Форма регистрации на семинар

[В начало]

СОВЕТЫ

Первый взгляд на затраты плана выполнения в Yukon Beta 1

По материалам статьи Joe Chang A First Look at Execution Plan Costs in Yukon Beta 1
Перевод Виталия Степаненко

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

Большинство формул затрат не изменились. Это формулы для поиска по индексу, сканирования таблицы, loop, hash и merge join'ов. Изменился Bookmark lookup. Bookmark lookup часто следует за использованием некластерного индекса для нахождения набора строк, где требуется больше информации о таблице, чем находится в индексе. Например, TableA имеет некластерный индекс по столбцу Col1. Для запроса SELECT * FROM TableA WHERE Col1 = x план выполнения может состоять из поиска по индексу столбца Co1l, сопровождаемого bookmark lookup по таблице для получения оставшейся информации по столбцам таблицы для нужных строк. В SQL Server версий 7.0 и 2000 план выполнения выглядел бы так, как показано на рис.1. В Yukon Beta 1 план выполнения выглядит так, как показано на рис.2 и 3.

Рис.1. План выполнения с Bookmark Lookup в SQL Server 7.0 и 2000.

Рис.2. План выполнения в Yukon Beta 1 для "RID" Lookup.

Рис.3. План выполнения в Yukon Beta 1 для поиска по некластерному индексу.

Это изменение в графическом представлении bookmark lookup на самом деле не изменяет порядок выполнения самой операции, но показывает более целостную картину выполнения операции. Во-первых, существует разница между bookmark lookup по таблице с кластерным индексом и без кластерного индекса. SQL Server 7.0 и 2000 не показывают этого, а Yukon эту разницу показывает. В таблице без кластерного индекса некластерный индекс имеет строку, страницу и информацию о файле для прямого указания на страницу со строкой. В таблице с кластерным индексом некластерный индекс имеет значение ключа кластерного индекса. В этом случае bookmark lookup выполняется совместно с операцией поиска по индексу.

Во-вторых, есть некоторое сходство между операциями bookmark lookup и loop join, поэтому изменение графического представления позволяет легче распознать операцию. Однако минусом является то, что операция отображается в более сложном виде, чем выводимый раньше простой символ операции bookmark lookup. В графическом представлении плана выполнения иногда лучше упростить части этого плана, которые уже поняты или неинтересны (относительно других более интересных частей плана выполнения).

В дополнение к изменению в графическом представлении плана выполнения для операции bookmark lookup, формулы расчета затрат для этой операции также изменились. В SQL Server 7.0 и 2000 операция bookmark lookup имела один набор формул расчета затрат, а операция loop join - другой набор таких формул. В Yukon Beta 1 старые формулы расчета затрат операции bookmark lookup были удалены и теперь существует только один набор формул расчета затрат для операций bookmark lookup и loop join. Набор формул расчета затрат тот же, что и старый набор формул расчета затрат версий 7.0 и 2000. Хотя это и более целостное представление операции, при этом есть положительные и отрицательные последствия.

Сначала давайте рассмотрим некоторые формулы расчета затрат. Операция поиска по индексу использует показанные ниже формулы, которые были установлены в 7.0 и остаются в Yukon Beta 1.

Затраты ввода-вывода =
0.006328500 + 0.000740741 на каждую дополнительную страницу (до 1 GB)
0.003203425 + 0.000740741 на каждую дополнительную страницу (более 1 GB)

Загрузка процессора = 0.000079600 + 0.000001100 на каждую дополнительную строку

Первая формула затрат ввода-вывода используется для систем с объемом памяти до 1 гигабайта включительно и с настройками памяти SQL Server по умолчанию (динамическая память). Вторая формула затрат используется для систем с объемом памяти более 1 гигабайта. Затраты на каждую дополнительную страницу относятся только к страницам нижнего уровня и не включают страницы промежуточного уровня.

Старые формулы расчета затрат в SQL Server версий 7.0 и 2000 для операций bookmark lookup были следующими:

Оценочные затраты ввода-вывода =
множество значений 0.006250000 (до 1 GB)
множество значений 0.003124925 (более 1 GB)

Оценочная загрузка процессора = 0.0000011 на каждую строку

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

Рис.4. Множество значений затрат ввода-вывода старой операции Bookmark Lookup как процент от количества строк.

Формулы расчета затрат на сканирование таблицы в SQL Server 7.0, 2000 и Yukon Beta следующие:

Затраты ввода-вывода = 0.0375785 + 0.000740741 на каждую дополнительную страницу

Загрузка процессора = 0.0000785 + 0.0000011 на каждую строку

Для формул расчета затрат в SQL Server 7.0 и 2000 подразумевается, что затраты плана выполнения с bookmark lookup в 7 раз больше для одной строки, чем затраты на сканирование каждой страницы при сканировании таблицы для систем с объемом памяти до 1 гигабайта включительно, и в 3.5 раза больше для систем с объемом памяти больше 1 гигабайта.

Сейчас можно спросить, почему старые затраты на операцию bookmark lookup для кажой дополнительной строки гораздо выше, чем затраты на страницу для сканирования таблицы. Вспомним, что в начале 1990-х годов память была очень дорогой по сравнению с настоящим временем. 16-мегабайтный модуль памяти стоил около 600 долларов. Обоснованным предположением в то время было то, что обычный сервер баз данных может иметь объем памяти, достаточный только для кэширования небольшой части общего объема данных. Т.е. скорее всего получение каждой строки в операции bookmark lookup будет сопровождаться дисковыми операциями ввода-вывода. Более того, для операции bookmark lookup каждая последующая строка в запросе, возможно, не является последующей строкой в таблице, поэтому выборка каждой строки может приводить к чтению данных из разных страниц. С другой стороны, сканирование таблицы потенциально может читать целые экстенты (8 страниц) за одну операцию ввода-вывода. Возможно, что затраты на физический дисковый ввод-вывод больше зависят от количества отдельных операций ввода-вывода, чем от количества данных. Если так, то это одно из возможных объяснений больших затрат на строку при выполнении операции bookmark lookup относительно затрат на страницу при сканировании таблицы.

Это объяснение является полностью умозрительным. Однако, если считать его верным, то также можно предположить, что формулы расчета затрат зависят от того, какой объем нужных данных находится в кэше буфера. В этом случае формула расчета затрат должна зависеть от индикатора, отражающего наличие данных в кэше, такого, как коэффициент заполнения кэша буфера (buffer cache hit ratio), чем от объема памяти в системе. Сервер с 512 мегабайтами памяти и базой данных в 256 мегабайт скорее всего имеет больший коэффициент заполнения кэша буфера, чем сервер с 4 гигабайтами памяти и базой данных в 100 гигабайт. Так что вполне понятно, что абсолютный объем памяти сам по себе - это плохой индикатор для использования того или иного варианта формулы расчета затрат.

Формулы расчета затрат на операцию bookmark lookup, использовавшиеся в SQL Server 7.0 и 2000, были заменены старыми формулами расчета затрат на операцию loop join, которые сейчас используются и для операции bookmark lookup, и для операции loop join. Но формулы расчета затрат для операции loop join сами могут вести себя необычно. Компонент loop join сам по себе - это относительно простая формула затрат процессора в 0.00000418 на каждую строку. Сложность содержится в операции поиска по индексу для внутреннего источника данных (inner source, IS). Во-первых, существуют как минимум 3 разных варианта формулы расчета затрат операции loop join для внутреннего источника данных, как показано на рис.5.

Рис.5. Известные варианты формулы расчета затрат операции loop join.

Первый вариант относится к обычным ситуациям, когда поисковый аргумент определен на обеих таблицах в объединении и где индекс на внутреннем источнике данных предваряется поисковым аргументом внутреннего источника данных и сопровождается условием объединения с результатом, при котором данные из внутреннего источника данных содержатся в небольшом количестве страниц. Второй вариант наблюдается, когда поисковый аргумент определен только на таблице внешнего источника данных (outer source, OS), а таблица внутреннего источника данных имеет индекс, используемый в условии объединения. Третий вариант наблюдается в тех случаях, когда поисковый аргумент определен на обеих таблицах, как в первом варианте, но внутренний код не ограничивается небольшим количеством страниц. Во всех трех вариантах затраты на строку для всей операции loop join составляют примерно 0.00015 для первых 132 строк. При количестве строк, большем 132, второй и третий варианты показывают очень резкий скачок затрат плана выполнения, более чем в 30 раз при переходе от 132 к 133 строкам. Нет никакой причины для превышения затрат операции loop join с 133 строками в 30 раз над затратами операции loop join с 132 строками на тех же таблицах. Первый вариант не показывает необычный скачок затрат при переходе от 132 к 133 строкам, а продолжает показывать затраты в 0.00015 на строку. Есть еще один известный вариант, когда таблица внутреннего источника данных маленькая и затраты в этом случае равны 0.0000796 на строку.

Для операций bookmark lookup используемая формула расчета затрат является вторым вариантом, т.к. нет явного поискового аргумента на таблице внутреннего источника данных и эта таблица не может быть маленькой, если обрабатывается множество строк. Итоговым результатом изменений при переходе от SQL Server 7.0 и 2000 к Yukon состоит в том, что затраты на операцию bookmark lookup изменились. Если раньше они были в несколько раз больше, чем затраты на страницу при сканировании таблицы, то теперь они в несколько раз меньше, кроме случаев, когда количество строк превышает 132 строки.

Таблица ниже суммирует примерные затраты плана выполнения и действительные затраты на каждую строку для операций bookmark lookup и loop join, и затраты на страницу для сканирования таблицы (не в режиме rowlock). Затраты плана выполнения для операций сканирования таблицы и loop join относятся к SQL Server 7.0, 2000 и Yukon Beta 1. Затраты плана выполнения для операции bookmark lookup относятся к SQL Server 7.0 и 2000. Затраты плана выполнения для операции bookmark lookup для Yukon Beta 1 - те же, что и показанные ниже затраты для операции loop join для 132 строк включительно. Для 133 или более строк затраты для операции loop join на строку намного выше. Показанные ниже затраты относятся к SQL Server 2000. В Yukon измерение этих затрат пока не производилось.

Операция	Затраты плана выполнения	Действительные затраты Pentium III	Действительные затраты Xeon
Bookmark – таблица без кластерного индекса (старые формулы)	~0.00625	~11K	~13K
Bookmark – таблица с кластерным индексом (старые формулы)	~0.00625	~15K	~21K
Loop Join (до 132 строк)	~0.00015	~17K	~24K
Сканирование таблицы (на страницу)	~0.0007407	~24K	~24K

Затраты плана выполнения выводятся в неопределенных единицах измерения. Действительные затраты измеряются циклами процессора, вернее, единицами времени, относящимися к частоте процессора (CPU clock). Для компьютеров на базе Pentium III частота процессора составляет от 600 до 733 мегагерц. Для компьютеров на базе Xeon частота процессора составляет от 2.0 до 2.4 гигагерц.

Действительные затраты на строку для операций bookmark lookup и loop join и затраты на страницу для сканирования таблицы не сильно различаются. Это больше различия между процессорами Pentium III и Xeon. Затраты на операцию bookmark lookup относительно ниже для таблиц без кластерного индекса, чем для таблиц с кластерным индексом.

Заключение

Главным изменением при переходе от SQL Server 7.0 и 2000 к Yukon Beta 1 является то, что затраты плана выполнения с операциями поиска по индексу и bookmark lookup, которые были сильно недооценены, сейчас, возможно, переоценены, кроме случая, когда обрабатываются более 132 строк. Объединение операции bookmark lookup с операцией loop join - изменение в принципе правильное и позитивное. Однако операция loop join нуждается в новой калибровке. Для большей аккуратности несколько разные формулы должны использоваться для RID таблиц (без кластерного индекса) и таблиц с кластерным индексом. Хотя эта разница не очень большая, но если графическое представление плана выполнения пытается показывать разные операции, то, естественно, формулы расчета затрат могут также использовать наиболее подходящие значения. Также желательно, чтобы формулы расчета затрат плана выполнения учитывали разницу в архитектуре процессоров. Также было бы желательно, чтобы формулы расчета затрат основывались на коэффициенте заполнения кэша буфера (buffer cache hit ratio), а не на абсолютном объеме памяти. Есть надежда, что в релизе Yukon'а будут сделаны по крайней мере некоторые необходимые улучшения в формулах расчета затрат плана выполнения.

[В начало]

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

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

Automating Smart-Client Report Deployments
Anthony Glenwright
Building reports is often easier than getting them into users' hands and making sure they're used correctly, but now you can use the SQL Server Reporting Services Web service to automate deployment and control execution of reports
Data Warehouse Appliances: Driving the Business Intelligence Revolution
Foster D. Hinshaw
Editor's Note: This article provides an overview regarding the use of an appliance approach for data warehousing infrastructure. Although it does not compare and contrast the appliance approach with the more traditional approaches, it does provide an explanation of this emerging technology
Page Life Expectancy a Reliable Indicator of SQL Server Memory Pressure
Brian Moran
Have you ever checked out the page life expectancy counter in Performance Monitor's Buffer Manager object? SQL Server Books Online (BOL) says the page life expectancy value is the "number of seconds a page will stay in the buffer pool without references." So, a buffer that has a 300-second page life expectancy will keep any given page in memory in the buffer pool for 5 minutes before the buffer pool flushes the page to disk—unless a process references the page
Inside SQL Server 2000's Memory Management Facilities
Ken Henderson
This column is excerpted from The Guru's Guide to SQL Server Architecture and Internals (Addison-Wesley, 2003) by Ken Henderson. Used by permission. All rights reserved
Microsoft SQL Server 7.0 and SQL Server 2000 Management Pack Guide
Tom Keane, Steve Wilson, Brenda Carter, James Hedrick, Scott Kendall
Microsoft SQL Server 7.0 and SQL Server 2000 Management Pack Refresh for Microsoft Operations Manager 2000 SP1
Simple Log Shipping in SQL Server 2000 Standard Edition
Ron Talmage
Enterprise Manager's log shipping utility is available only for the SQL Server 2000 Enterprise Edition and SQL Server 2000 Developer Edition. So can you log-ship databases that run on SQL Server 2000 Standard Edition? Microsoft's answer for the Standard Edition is the Simple Log Shipper tool, which you can find in the Microsoft SQL Server 2000 Resource Kit. Simple Log Shipper uses a linked-server relationship between the primary server and the secondary server. The log shipping activity is controlled from a stored procedure called sp_ShipLog, which you run in a SQL Server Agent job on the primary server. This stored procedure backs up the primary server database's transaction log to a Universal Naming Convention (UNC) file location and makes a remote procedure call (RPC) to sp_ApplyStandbyLog on the secondary server to restore the log file to the secondary database. These stored procedures typically are located in each server's master database, but that location (which the Simple Log Shipper documentation recommends) isn't a requirement. Simple Log Shipper doesn't provide cleanup for transaction-log backup files, so you have to archive them and delete the old ones manually. You can monitor Simple Log Shipper by reading the primary server's SQL Server Agent job history, SQL Server error log, and Windows event log
Log Shipping in SQL Server 2000, Part 2
Ron Talmage
Role changes, role reversals, and positioning the monitor server. When your production database server goes down—as the result of planned maintenance or an unexpected event—you want to feel secure in the knowledge that the database is intact on a standby server. A well-designed log shipping operation, which ships a database's transaction logs from your primary server to a standby server, can give you this confidence. SQL Server 2000 Enterprise Edition and SQL Server 2000 Developer Edition support log shipping as a built-in Enterprise Manager utility. The Microsoft SQL Server 2000 Resource Kit comes with a set of unsupported stored procedures for log shipping in other SQL Server 2000 editions (see the sidebar "Simple Log Shipping in SQL Server 2000 Standard Edition," page 36, for details), and the Microsoft BackOffice Resource Kit (BORK) 4.5 provides an unsupported method of log shipping for SQL Server 7.0. In "Log Shipping in SQL Server 2000, Part 1," December 2001, InstantDoc ID 23056, I described how to set up, reconfigure, and monitor log shipping. In this article, let's look at how you can change the roles of the primary and secondary servers, how to fully reverse their roles, and where to place the monitor server for the most effective monitoring
Analysis About Analysis Services
Ramunas Balukonis In this article I’ll demonstrate how one can learn more about the queries that are sent to analysis services
Optimized ADO.NET
John Goodson
Developing performance-oriented .NET applications is not easy. The .NET standard includes only basic guidelines and interface definitions to help programmers develop .NET applications. In addition, .NET data providers do not throw exceptions to say that your code is running too slowly
Identifying external or internal table fragmentation
Eli Leiba
This article describes how to identify tables that are fragmented internally (i.e., fragmentation inside data pages) or externally (i.e., extents are fragmented)
Adding T-SQL functions to SQL Server system schema
Eli Leiba
Sometimes when dealing with many applications that need similar functionality, the best thing to do is to write functions directly to the system's schema. This enables all databases within the server to execute the function as though it was a regular expansion of the T-SQL language
Manageability and business analytics with SQL Server 2005
Sara Cushman
Though plenty of people have already caught a glimpse of SQL Server 2005, and some companies are even using Beta 2 in production environments, most enterprises won't be seeing the latest release of Microsoft's DBMS until it ships early next year. But attendees at last week's 2004 PASS Community Summit in Orlando were eager to learn about what's ahead
The database dilemma - and the solution you’ve been waiting for
xprime
The database is a vital and critical element of business infrastructure—much more than a basic system for information storage and retrieval. Unfortunately, the database has also become the single largest point of pain in the enterprise. Generations of applications have been written to allow users to access the business logic and information held within the database. However, over time the performance of these applications has degraded to the point of being unusable. Why is that?
Seven Misconceptions about Data Quality
Rick Sherman
This article might help you recognize the data quality problems you have been in denial about. Editor's note: Rick Sherman is a monthly columnist for DM Review. This BI Briefs column originally was posted to DMReview.com on June 4, 2004. Check out other columns by Rick Sherman at http://www.dmreview.com/authors/author_sub.cfm?authorId=32168
The SQL of OLAP
Michael Gonzales
Don't overlook the core strength of your OLAP technology solution: SQL.When considering online analytic processing (OLAP), architects often focus on issues such as which dimensions to include, what facts are relevant, how often to refresh the data contents, and so on. Among these issues, the OLAP language is often overlooked. And of all the OLAP-centric languages, the most often ignored is SQL itself. To overlook the language of your OLAP technology solution is to ignore its real strength, or weakness, because this language dictates your applications' flexibility and complexity
Talking Data Warehouse Dimensions, Part 1
Mladen Golubovic
Business flow dictates attempts to integrate multiple lines of business within the enterprise
Introduction to MSSQL Server 2000 Analysis Services: Reporting Options for Analysis Services Cubes: ProClarity Part II
William Pearson
In this article, we will continue our exploration of ProClarity in the same hands-on manner, with a focus on exposing more of the rich analysis and reporting capabilities of the application
Incident Response - Responding to an Incident
Steve Jones
Disaster Recovery planning is something that everyone says you should do. Everyone wants a detailed plan that spells out exactly what you will do, especially those Sarbannes-Oxley auditors. But in reality, a detailed plan won't work and if you expect a detailed plan to succeed, you'll be in trouble. People need to be able to think on their feet, react, and make up for documents that aren't up to date or don't cover the situation
Introduction to MSSQL Server 2000 Analysis Services: Reporting Options for Analysis Services Cubes: ProClarity Part II
William Pearson
In Part I of this article, we returned to the objectives of an earlier subseries, Reporting Options for Analysis Services Cubes. As we stated in that set of articles, our focus was to respond to a constant request from readers: to explore options beyond the Analysis Manager / Sample Application interfaces for analyzing and reporting data in MSAS cubes. I began an examination of another such option, ProClarity, based upon a suggestion I received from a reader, and upon my own favorable experiences with this outstanding tool in recent months
Securing Your SQL Server 2005 Express Edition Server
William Vaughn
Get introduced to SQL Server Express, learn how to install and configure it in a secure manner, plus get information on the basics of SQL Server security. (15 printed pages)
Microsoft Great Plains – SQL Querying Trivia
Andrew Karasev
This is beginner level SQL scripting article for DB Administrator, Programmer, IT Specialist.Our and Microsoft Business Solutions goal here is to educate database administrator, programmer, software developer to enable them support Microsoft Great Plains for their companies. In our opinion self support is the goal of Microsoft to facilitate implementation of its products: Great Plains, Navision, Solomon, Microsoft CRM. You can do it for your company, being aware on simple data repair techniques and appealing to Microsoft Business Solutions Techknowledge database. This will allow you to avoid expensive consultants visits onsite. You only need the help from professional when you plan on complex customization, interface or integration, then you can appeal to somebody who specializes in these tasks and can do inexpensive nation-wide remote support for you
Islands and Gaps in Sequential Numbers
Alexander Kozak
As you know, relational databases are set-based and aren't particularly suited for row-at-a-time processing. However, in situations with heavily fragmented data (lots of gaps), you may find that row-based processing does better than set-based processing. Alexander Kozak demonstrates
Introduction to MSSQL Server 2000 Analysis Services: Partitioning a Cube in Analysis Services - An Introduction
William Pearson
We have touched upon partitions over the life of the Introduction to MSSQL Server 2000 Analysis Services series, as well as within other series at Database Journal. We recently discussed partitioning more specifically within our article Basic Storage Design, within which we introduced the Storage Design Wizard. The Storage Design Wizard, as we discovered, enables us to manage aggregations on a partition-by-partition basis when working with a multi-partitioned cube. We noted that, if a cube we are optimizing through the use of the Storage Design Wizard contains multiple partitions, we are forced to select a partition from the outset, as we can only design storage for a single partition at a time
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
Restore multiple DTS packages
Muthusamy Anantha Kumar
This article examines how to take advantage of VB Script and MS-DOS batch files to restore multiple DTS packages stored in the form of structured storage files from one folder to a SQL Server box. When many DTS packages reside as structured storage files, it can be tiresome to restore those DTS packages one by one using Enterprise Manager. [Fig 1.1] As described in my previous article, Automating "Save DTS package," there may be cases where you have multiple DTS packages stored in a folder
SQL: Assertions
Rudy Limeback
I have two tables, one called nurses and the other called pharmacist. Both tables record their license number. I need to write an assertion that ensures that all licenses of nurses and pharmacists have been renewed in the last two years. Thank you for your help

[В начало]

ФОРУМ SQL.RU

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

Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
Кто на чем пишет клиентов под SQL Server?
Новые упражнения на http://sql.ipps.ru
Tool Вы знаете что твориться на ваших 10-30+ серверах ?
Суррогатные или естественные
Книга по SQL 2000
Книга по SQL
Правильно ли составлены индексы:
SQL Server Health and History Tool (SQLH2) Reports
Запрос выполняется очень долго!!!
Какую я только что весчь поймал!
Как включить использование hyper-threading в MSSQL2000?
СЕМИНАР: Репликация & Особенности разработки приложений
MSSQLServer. database
Серьезный вопрос и чуть-чуть наглости
SQL 2005 Beta 2
преобразовать datetime к decimal или наоборот с учетом зоны
UDF как вернуть динамический запрос?
Книга по Reporting Service
вопрос про индексы

[В начало]

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

Средство мониторинга блокировок, как бы эффективней получить скрипт приведший к блокировке.
Log Shipping Monitor не работает:-(
Книга по DTS
Помогите с SQL 7.0
Проблема с MS DTC
ТОП 10 самых популярных вопросов
Репликация транзакций
DBCC CHECKDB. Проблема.
Как создать сalculated columns для MS SQL в Visio EA?
Не запускается агент дистрибьютора
Странный эффект при создании объектов
Проголосуем за хорошую книжку...

[В начало]

ПОЛЕЗНОСТИ

Microsoft SQL Server 2000. Справочник администратора

ДеЛюк С.А., Уолен Э., Рединг ДЖ., Гарсия М.Ф. ISBN: 5-9570-0028-0, Издательство: Эком. Год выпуска: 2004. Тип переплета: мягкий. 2-е изд. Тираж книги: 3000. Формат книги: 70х100/16. Количество страниц: 976 В книге содержатся все необходимые сведения об установке, конфигурировании и эксплуатации SQL 2000 Server для профессионалов в области информационных технологий. Рассматриваются вопросы установки и конфигурирования SQL Server, создания баз данных и объектов, использования Microsoft Cluster Services (MSCS), манипулирования данными, администрирования и использования SQL Server, управления с помощью T-SQL таблицами, триггерами, базами данных, доступа к SQL Server через Internet, настройек и особенностей применения репликаций, Microsoft Distributed Transaction Coordinator (MS DTC), работы с аналитическими службами SQL Server. Рассмотрены типичные проблемы, связанные с эксплуатацией SQL Server, и способы их решения.

[В начало]