DBA и безопасность

Microsoft выпустил заплату, которая устраняет уязвимость защиты Windows 2000, позволяющую подбирать пароль учётной записи, даже если администратор домена установил политику блокировки учётной записи после нескольких неудачных попыток регистрации.
http://www.microsoft.com/technet/security/bulletin/fq00-089.asp
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25606

SQL Server 7.0 Service Pack 3 Beta version (По материалам статьи Brian Knight на swynk.com)

Корпорация Microsoft анонсировала бета версию SQL Server 7.0 Service Pack 3 (SP3).
http://www.microsoft.com/downloads/search.asp?
SP3 устраняет около 190 ошибок SQL Server и 15 ошибок для OLAP. Microsoft не рекомендует использование SP3 на промышленных серверах. С помощью команды SELECT @@ VERSION, вы можете определить текущую версию:

7.00.623 Original SQL Server 7.0
7.00.699 Database components SP1
7.00.842 Database components SP2
7.00.961 Database components SP3

Чтобы определять версию OLAP, просто откройте OLAP Manager и выбираете About Microsoft SQL Server OLAP в меню Help:

7.0.1073 Original OLAP Services release
7.0.1295 OLAP Services SP1
7.0.1458 OLAP Services SP2
7.0.1507 OLAP Services SP3 Beta version

Для установки полного SP3 Вы должны иметь свободными 389МБ, а только для SQL Server - 193МБ. Обязательно сделайте резервные копии. Если вы устанавливаете service pack в систему с репликациями, устанавливаете SP3 в начале на Distributor, а потом на Publisher и Subscribers. Перед установкой SP3 опустите все сервисы SQL Server и закройте все панели управления.

Отмена установки SP3

Процесс отката назад установки SP3 не является тривиальным и сводится к тому, что Вы должны отсоединить ваши базы данных, используя команду SP_DETACHDB. Затем, повторно установите SQL Server 7.0, а потом установите надлежащий сервисный пакет. Наконец, используя команду SP_ATTACHDB, прикрепляйте файлы базы данных.

Сокращение размера Transaction Log в SQL Server 2000 с помощью DBCC
(По материалам Q272318)

Команда DBCC SHRINKFILE для урезания log в SQL Server 2000 больше не является отложенной операцией. DBCC SHRINKFILE пытается сокращать файл немедленно. Однако, в некоторых случаях, необходимы дополнительные действия для того, что бы журнал был сокращён до нужного размера.
При выполнении DBCC SHRINKFILE, SQL Server 2000 удаляет виртуальные журналы, чтобы в целом получить заданный размер журнала. Если заданный размер не достигнут, SQL Server размещает фиктивные входы журнала в последний виртуальный журнал, пока виртуальный журнал не будет заполнен, а потом перемещает заголовок журнала в начало файла. В таком случае, чтобы завершить сокращение размера журнала:

1. Выполнить инструкцию BACKUP LOG, чтобы удалить неактивную часть журнала.
2. Выполнить DBCC SHRINKFILE снова, задав желательный размер.

Например:

DBCC SHRINKFILE(pubs_log, 2)
(Если нужный размер не достигнут)
BACKUP LOG pubs WITH TRUNCATE_ONLY
DBCC SHRINKFILE(pubs_log,2)

ГОТОВИМСЯ К ТЕСТУ ПО 1139А

ШПАРГАЛКА №5 Продолжение (обзор официального курса Microsoft)
Архив шпаргалок Вы найдёте на следующих сайтах:
http://pilgrim.rostov-na-donu.ru/sql/default.htm
http://mssqlhelp.com.ru
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself

Создание и хранение резервных копий

Вы можете создавать постоянные или разовые файлы резервных копий. Наиболее распространены постоянные копии, хотя иногда бывает нужно сделать разовую копию. Постоянные файлы (устройства) резервных копий (BackUp Devises) применяются при неоднократном резервном копировании, что позволяет автоматизировать этот процесс. Создать устройства резервирования можно в SQL SEM или с помощью системной хранимой процедуры sp_addumpdevice. Резервными устройствами могут быть файлы на дисках, ленты или именованные каналы. Информация об этих устройствах записывается в системные таблицы sysdevice базы master. Каждому устройству присваивается логическое и физическое имя. Допускается иметь не более 32 устройств резервных копий. Синтаксис sp_addumpdevice следующий:

sp_addumpdevice        [@devtype = ] ‘ТипУстройства’,
                                         [@logicalname = ] ‘НазваниеУстройства’,
                                         [@physicalname = ] ‘ФизическоеИмя’
                                         [, { [@cntrltype = ] ТипКонтроллера | [@devstatus = ] ‘СостояниеУстройства’}]

Тип устройства может быть: TAPE, DISK или PIPE, например:

USE master
EXEC sp_addumpdevice ‘TAPE’, ‘ModelTapeBackup’, ‘\\.\tape0’

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

BACKUP DATABASE {database_name | @database_name_var}
TO <backup_device> [,...n]
[WITH
        [BLOCKSIZE = {blocksize | @blocksize_variable}]
        [[,] DESCRIPTION = {text | @text_variable}]
        [[,] DIFFERENTIAL]
        [[,] EXPIREDATE = {date | @date_var}
          | RETAINDAYS = {days | @days_var}]
        [[,] FORMAT | NOFORMAT]
        [[,] {INIT | NOINIT}]
        [[,] MEDIADESCRIPTION = {text | @text_variable}]
        [[,] MEDIANAME = {media_name | @media_name_variable}]
        [[,] [NAME = {backup_set_name | @backup_set_name_var}]
        [[,] {NOSKIP | SKIP}]
        [[,] {NOUNLOAD | UNLOAD}]
        [[,] [RESTART]
        [[,] STATS [= percentage]]
]

Внимательно изучив многочисленные параметры, можно прийти к следующим упрощениям:

1. Для создания разовой (временной) копии, например базы NorthWind, можно использовать такую конструкцию:

USE master
BACKUP DATABASE NorthWind TO DISK = ‘E:\\BACKUPS\BackupOnseNorthWind.bak’

Как видим, вместо backup_device здесь используется прямое указание на файл диска "E:". Допускается также использовать прямую ссылку местоположения файла на другом сервере. В таком случае, учётная запись, от имени которой стартует MSSQLServer должна иметь соответствующие права для доступа в выбранный каталог другого компьютера.

2. Можно существенно ускорить процесс резервного копирования, если у Вас имеется несколько однотипных устройств (приводов магнитных лент или дисков). Для этого введено понятие MEDIANAME (имя до 128 символов) описывающее резервный набор этих самых устройств. Т.е., в случае использования дисковых устройств, можно писать копию сразу в несколько файлов (параллельно - последовательно), что соответственно увеличивает скорость копирования. Резервные наборы могут содержать, как постоянные, так и временные файлы. Причём, если Вы включили файл резервной копии в такой набор, то использовать его можно только в этом наборе. Если Вы, все-таки, создадите копию в одном из файлов набора, то для дальнейшего использования набора в целом потребуется переформатировать все его файлы. Также бессмысленно форматировать только один файл набора, поскольку это нарушит целостность копий всех файлов набора.

3. Резервная копия может присоединятся к существующему устройству (по умолчанию) или затирать предыдущие копии. Т.е. может выполняться предварительная инициализация соответствующего устройства но данные заголовка файла сохраняются. Для этого используют параметр INIT или NOINIT. Правда, если первый файл резервного набора располагается на устройстве с меткой стандарта ANSI, которая запрещает перезаписывать существующие копии, то использовать параметр INIT не удастся. Ещё одним препятствием, способным помешать резервному копированию, может стать установка параметра EXPIREDATE, определяющего срок использования устройства резервирования. Также, копия не получится, если Вы попытаетесь записать копию в один из файлов существующего резервного набора. Во многих случаях, когда Вы испытываете трудности с устройствами резервного копирования, на выручку может прийти параметр FORMAT (есть ещё и NOFORMAT). С помощью его можно записать копию даже в принадлежащий резервному набору файл. В отличии от INIT, перезаписи подлежит всё, включая заголовок файла, причём, если файл входит набор, заголовок переписывается во всех файлах набора (при этом, правда, набор разбивается). Новый заголовок определяется данными из MEDIANAME и MEDIADESCRIPTION.

4. Существуют параметры, которые применимы только к лентам, как сменным устройствам. Кроме этих отличий, есть ещё и специфическое ограничение для магнитных лент: привод магнитных лент должен быть подключён локально, т.е. к тому серверу, где "крутится" SQL. Для того, что бы делать копии на ленточное устройство, подключённое к другому серверу, Вам потребуется использовать специальное ПО третьих фирм, которое будет получать данные по именованному каналу. Для отделения копий друг от друга, на ленту записываются метки, которые определяют имя базы, время создания копии, дату и тип резервного копирования (об этом позже). Начиная с версии 7.0, SQL сервер записывает информацию на ленты в стандартном для Windows NT формате, и поэтому допускается совмещение копий сервера баз данных и операционной системы на одной ленте. По умолчанию, после завершения копирования на ленту, происходит её выгрузка из привода (как при использовании параметра UNLOAD). Так будет происходить, пока Вы не примените NOUNLOAD. Другой параметр BLOCKSIZE применяется в комплекте с параметрами FORMAT, INIT или SKIP. Применяйте его, если Вас не устраивает стандартный размер блока, при копировании на ленту (например, если кроме баз данных Вы копируете обычные файлы, средний размер которых существенно меньше размера блока). При форматировании ленты нет необходимости использовать параметры INIT и SKIP, они и так выполнятся. В заголовках ленты содержатся метки ANSI, которые могут препятствовать записи копии (срок действия или права на запись). Что бы преодолеть это препятствие используют параметр SKIP. По умолчанию, действует NOSKIP, т.е. все эти заголовки читаются и учитываются. И в довершении ко всему, если Ваша копия не помещается на одну ленту, возобновить копирование на следующий том с точки прерывания можно повторным запуском BACKUP с параметром RESTART.

5. Кроме полного резервного копирования, существуют ещё схемы, позволяющие иметь актуальную копию с меньшим отвлечением ресурсов, чем автоматическое создание полной копии во временном интервале использования базы и в автоматическом режиме. Одна из таких схем – разностное резервное копирование, которое определяется параметром DIFFERENTIAL. Разностная копия создаётся на базе полной и предусматривает отписывание на устройство резервирования фрагментов базы, которые были изменены за время, прошедшее с последнего полного копирования. Для этого сравнивается Log Sequence Number (LSN) – порядковый номер записи в журнале транзакций, на каждой синхронизируемой с копией странице, с тем LSN, который был последним в предыдущей полной копии. Копирование происходит экстентами, и в копию попадают те экстенты, в которых встречаются страницы с найденным LSN большим, чем в полной копии. Копированию подлежат также все выполняющиеся в это время операции и все не завершённые транзакции. Журнал транзакций целиком не копируется. Следует отметить, что хронология обработки транзакций при таком копировании не соблюдается. Т.е., если одна запись менялась в промежутке между копированиями несколько раз, в копии отразится только последний результат. Если Вы собираетесь использовать эту схему резервного копирования, лучше выработать для себя некие правила именования файлов, содержащих разностные копии, так будет проще разобраться, где у Вас полные, а где у вас иные копии.

Ещё одной схемой резервирования является отписывание в предварительно созданную полную копию записей журнала транзакций. Для этих целей используется оператор BACKUP LOG. При таком подходе, в копию попадают записи журнала транзакций от момента, когда была создана полная копия или отписывались транзакции последний раз и до конца текущего журнала. При этом от журнала будет отсечена неактивная его часть вплоть до начала активного фрагмента, т.е. до того места, откуда начинаются активные в этот момент транзакции и далее, до конца журнала. Поскольку, после отписывания журнала в копию происходит очистка завершённых транзакций, таким способом можно удерживать размер журнала в разумных пределах (он не будет "распухать" у вас до следующей полной копии). Кроме того, соблюдается хронология выполнения операций, т.е. можно их восстанавливать в обратном порядке, как они выполнялись, а не последнее значение (разностная копия).
Возможен случай, когда в промежутке между очередным резервным копированием журнала (по описанной выше схеме) у Вас будет повреждена база данных или даже утеряна полностью. Не отчаивайтесь, выход есть. Правда, для этого нужно, что бы "выжил" файл, содержащий журнал транзакций. Поскольку в журнале останутся записи после Вашего последнего резервного копирования, Вы можете применить оператор BACKUP LOG с параметром NO_TRUNCATE, после чего всё содержимое журнала транзакций попадёт в Вашу резервную копию, даже если сама база уже не доступна. Разумеется, усечения журнала транзакций не происходит и у Вас появляется возможность восстановить данные на момент сбоя. Вы восстанавливаете базу из имеющейся копии, а потом восстанавливаете транзакции из журнала, которые Вы скопировали с параметром NO_TRUNCATE. Забыл ещё одно непременное условие: кроме журнала, у Вас должны обязательно выжить .mdf файл этой базы, где хранятся системные таблицы и база master.
Параметр TRUNCATE_ONLY или NO_LOG в увязке с BACKUP LOG может помочь Вам просто очистить журнал. Надеюсь, Вы сделаете сразу после этого резервную копию. При этом активная часть журнала остаётся не тронутой. Такая операция может понадобиться, если журнал разросся до такой степени, что заполнил всё свободное дисковое пространство и пользователи не могут больше вносить изменения. Я же, искренне надеюсь, что Вам доведётся прибегать к подобной операции только в тестовых условиях, когда потеря данных не критична. Есть в таком подходе и один приятный момент: дело в том, что выполненная после очистки журнала полная копия получится меньше, чем обычная (за счёт отсутствия в ней не активных записей журнала). Этот трюк можно проделать, если Ваша база чуть – чуть не помещается на устройство резервирования. Кроме того, операция усечения журнала не регистрируется. Эффекта автоматического усечения журнала, после каждого запуска контрольной точки, можно получить установкой в TRUE параметра базы данных truncate log on check point. Завершённые транзакции будут удаляться из журнала, что не даст ему сильно расти. Правда, в таком режиме работы базы Вы на сможете отписывать транзакции в резервную копию, а следовательно, восстановлению подлежит только то, что было до этого резервировано.

6. Если база данных храниться у Вас не в одном файле, а в некоторой группе файлов, можно эти файлы резервировать выборочно. Такой подход наиболее часто применяют для очень больших баз данных. Исходный синтаксис в таком случае будет немного расширен. Кроме имени базы данных или её номера, можно через параметр FILE или FILEGROUP задать набор конкретных логических имён файлов, которые будут копироваться. Через запятую можно указывать до 16-ти таких имён. При такой схеме копирования, лучше копировать журнал в отдельный файл. Для исключения путаницы, лучше создать расписание таких копий. Вот пример резервирования выбранного, седьмого файла:

BACKUP DATABASE MyFirsDB
FILE = File7 TO File7Backup
BACKUP LOG MyFirsDB to myfirsdbLOGbackup

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

Продолжение следует

ПОЛЕЗНОСТИ

Вышла в свет книга "Освой самостоятельно SQL за 24 часа". Авторы: Рональд Р. Плю, Райан К. Стефенс. Эта книга предназначена для тех, кто стремится самостоятельно освоить технологии управления реляционными базами данных с помощью языка структурированных запросов (SQL), но не имеет соответствующего опыта. Книга может оказаться полезной и тем, кто уже имеет определенный опыт работы с реляционными базами данных, но испытывает потребность в дополнительной информации по созданию структуры базы данных и манипулировании ее данными. Эта книга является, прежде всего, учебником, содержащим теоретические материалы, примеры и упражнения, начиная с самого низшего уровня, соответствующего начальному знакомству с изучаемым предметом. Книга не предназначена для тех, кто имеет значительный опыт работы с реляционными базами данных и постоянно использует SQL. Данная книга не является справочным пособием и не должна рассматриваться как таковое.
На Web-странице издательства Sams по адресу http://www.samspublishing.com вы найдете все примеры использующегося на страницах книги программного кода, а также программный код, необходимый для создания образцов таблиц и ввода данных в таблицы, о которых идет речь в книге (Приложения В и Г).

Новые технические статьи Microsoft:

Q274255 - PRB: ADOXCE Error Message: "..Specified type was invalid" for SQL CE Table
http://support.microsoft.com/support/kb/articles/Q274/2/55.asp
Q276985 - HOWTO: Use SQL CE OLE DB Provider-Specific Properties in eVB
http://support.microsoft.com/support/kb/articles/Q276/9/85.asp
Q273580 - HOWTO: Look Up Error Codes Related to Microsoft SQL Server CE
http://support.microsoft.com/support/kb/articles/Q273/5/80.asp
Q274112 - INFO: Performance Tips and Efficient Ways to Handle Memory for SQL CE
http://support.microsoft.com/support/kb/articles/Q274/1/12.asp
Q274747 - PRB: Registered Remote SQL Servers May Be Lost from SQL Server 2000 Enterprise Manager
http://support.microsoft.com/support/kb/articles/Q274/7/47.asp
Q271566 - PRB: SQL Server Comparisons Between Columns and Constants with Different Data Types
http://support.microsoft.com/support/kb/articles/Q271/5/66.asp
Q271853 - PRB: READTEXT on Text Nullable Columns May Fail at a Replication Subscriber
http://support.microsoft.com/support/kb/articles/Q271/8/53.asp
Q274588 - BUG: SELECT with GROUP BY and WITH ROLLUP Results in Access Violation
http://support.microsoft.com/support/kb/articles/Q274/5/88.asp
Q279080 - PRB: Sqldiag Utility Exits if SQL Server Service Is Not Started
http://support.microsoft.com/support/kb/articles/Q279/0/80.asp
Q279083 - BUG: Books Online Example Stored Procedure Sp_SetMark
http://support.microsoft.com/support/kb/articles/Q279/0/83.asp
Q275436 - BUG: Distribution Agent Fails When Validating Publication with Stored Procedure Articles
http://support.microsoft.com/support/kb/articles/Q275/4/36.asp
Q278016 - BUG: Unable to Create Table in Enterprise Manager After Deleting a Column with Description
http://support.microsoft.com/support/kb/articles/Q278/0/16.asp
Q272318 - INF: Shrinking the Transaction Log in SQL Server 2000 with DBCC SHRINKFILE
http://support.microsoft.com/support/kb/articles/Q272/3/18.asp
Q278698 - FIX: Exception Access Violation Encountered During Compile of Hash Match Team Plan
http://support.microsoft.com/support/kb/articles/Q278/6/98.asp
Support WebCast: Cascading Referential Integrity Constraints in SQL Server 2000
http://support.microsoft.com/servicedesks/webcasts/wc101200/wcblurb101200.asp
Support WebCast: SQL Server 2000 Profiler: What's New and How to Effectively Use It
http://support.microsoft.com/servicedesks/webcasts/wc111400/wcblurb111400.asp
Troubleshooting SQL Connectivity Error- "10004 Unable to connect..."
http://support.microsoft.com/support/sql/content/connect/ntsupp.asp
Q236825 - PRB: #deleted Seen When SQL Server 7.0 Tables Containing Numeric and Text fields Are Opened
http://support.microsoft.com/support/kb/articles/Q236/8/25.asp
Q237980 - INF: How to Convert an Access Database to SQL Server
http://support.microsoft.com/support/kb/articles/Q237/9/80.asp
Q257767 - PRB: Cannot Open Pubs Table Image Data Through Microsoft Access Link
http://support.microsoft.com/support/kb/articles/Q257/7/67.asp
Q269697 - BUG: SPID Returns to ROLLBACK Status When You Cancel a SELECT Statement with a Parallel Plan
http://support.microsoft.com/support/kb/articles/Q269/6/97.asp
Q277848 - BUG: Error Message "Table Corrupt Object ID 0, index ID 0, page ID.." Occurs When You Run DBCC DBREINDEX in SQL Server
http://support.microsoft.com/support/kb/articles/Q277/8/48.asp
Q275912 - BUG: Generated Scripts Include ON INSERT/DELETE CASCADE Statements When Scripting SQL Server 7.0 Compatible Features
http://support.microsoft.com/support/kb/articles/Q275/9/12.asp
Q275518 - BUG: Updating Text Column with Instead Of Trigger Inside of a Stored Procedure Causes AV
http://support.microsoft.com/support/kb/articles/Q275/5/18.asp
Q279857 - BUG: Error 3910, "Transaction Context in Use by Another Session"
http://support.microsoft.com/support/kb/articles/Q279/8/57.asp

Получить эти статьи можно по этой ссылке: mailto:mshelp@microsoft.com?subject=Q274797, Q274798, Q274799, Q273580, Q274112, Q274747, Q271566, Q271853, Q274588, Q279080, Q279083, Q275436, Q278016, Q272318, Q278698, Q236825, Q237980, Q257767, Q269697, Q277848, Q275912, Q275518, Q279857

ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ

Милые Дамы и уважаемые Господа!
Хочу извиниться перед теми подписчиками, кто получает рассылки в текстовом виде. К сожалению, из-за хронической нехватки времени, я вынужден готовить выпуски рассылки в HTML формате, а тестовый вариант получается путём конвертации на сервере subscribe.ru введённого HTML варианта в текстовый формат. Повлиять на качество этой конвертации я не могу. Вводить оба варианта не позволяет скрипт, который предназначен для этих целей на сервере рассылок. Всё это привело к тому, что читаемость текстового варианта существенно пострадала, а значительная доля подписчиков текстового варианта отказалась от получения рассылки.
Мои познания в разметке страниц пока ещё не велики, но я обязуюсь поработать над тем, как "убить сразу двух зайцев". С другой стороны, призываю подписчиков текстовой версии не спешить полностью отказываться от рассылки, а просто поменять формат подписки на HTML.
В последнее время существенно возросла посещаемость архивов рассылки, что косвенно повлияло на отток подписчиков в пользу чтения выпусков в архивах. Я не противник такого подхода, но хочу обратить Ваше внимание, что в архивах не храниться информация, которая имеет разовый, сиюминутный характер. Таким образом, если Вы хотите получать оперативную информацию в полном объёме, не отказывайтесь от рассылки.
И ещё, если Вы решили отказаться от подписки на мою рассылку, очень прошу Вас, напишите мне, почему Вы пришли к такому решению. Возможно, я смогу учесть это в последующих выпусках.
Теперь о форуме рассылки. Вашими стараниями, активность посещения форума резко возросла. Поэтому, моё следующее предложение, наверное, будет выглядеть не логичным. В настоящее время у меня наладился хороший контакт с Александром - автором и исполнителем проекта SQL.RU. Как многие из Вас знают, на его сервере также организован форум (конференция) по проблемам MS SQL Server, и, надо отдать должное, этот форум посещается значительно активнее, чем форум рассылки. Мало того, появилась практика задавать один и тот же вопрос в обоих форумах. Я сам посещаю оба форума и ничего, кроме путаницы в таком положении вещей не нахожу. Посовещавшись с Александром, мы решили, что не имеет смысла дублировать одну и ту же задачу, и предлагаем Вам, в качестве основного, использовать форум:
http://www.sql.ru/cgi-bin/UltraBoard/UltraBoard.pl
Для Вашего и нашего удобства, пожалуйста, зарегистрируйтесь, как постоянный участник этой конференции (форума), это поможет нам в будущем оказывать более персонализированные услуги.
Предложение Вам посещать конференцию на SQL.RU не означает, что форум рассылки немедленно прекратит своё существование. По крайней мере, ещё 2-3 месяца я не буду ставить на нём "крест" и не откажусь от его модерирования. Просто в предлагаемой Вам конференции можно рассчитывать на более быструю и более качественную помощь. Кроме того, обсуждаемые там темы крайне интересны и для новичков и для профи.
И последний вопрос, который я бы хотел поднять. Дело в том, что (как Вы наверное заметили) не очень высокое качество рассылки и других аналогичных проектов, организованных на энтузиазме Ваших сограждан, является следствием отсутствия необходимой материальной базы и времени (в смысле: время – деньги). С другой стороны, эти ресурсы (какими бы убогими они не были) оказались востребованными. По большому счёту, это дело, которое стоит того, что бы ему посвятить не только несколько часов перед сном. В общем, если по существу, появилось желание сделать из хобби нормальный коммерческий проект, со всеми вытекающими из этого для Вас преимуществами. Теперь дело за возможностями. Статистика аудитории рассылки показывает, что её читают сотни руководителей коммерческих и не коммерческих организаций. К ним я и обращаю свой призыв: давайте объединим свои усилия и посмотрим, как можно с обоюдной выгодой создать достойный (для нашего отечественного DBA или SQL – программиста) ресурс, который бы ни в чём не уступал зарубежным аналогам, но был бы ориентирован на русскоязычную аудиторию. Если Вы сочли эту идею достаточно интересной, напишите, пожалуйста, мне о своей готовности обсудить детали нового проекта.

ДОСТУПНЫЕ РЕСУРСЫ РАССЫЛКИ:

СТРАНИЦА КАТАЛОГА
http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself
Зеркало в Ростове-на-Дону и АРХИВ №1
http://pilgrim.rostov-na-donu.ru/sql/default.htm
Зеркало в Cанкт-Петербурге и АРХИВ №2 (Возможны проблемы с доступом)
http://mssqlhelp.com.ru
АРХИВ на SUBSCRIBE.RU
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself
СТАТИСТИКА
http://subscribe.ru/stat/comp.soft.winsoft.sqlhelpyouself
ФОРУМ
http://www.sql.ru/cgi-bin/UltraBoard/UltraBoard.pl
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum