Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#099<< #100 |
СОДЕРЖАНИЕ
ОЧЕРЕДНОЙ ЮБИЛЕЙ ПРОЕКТА SQL.RU Вот и прошёл ещё один, уже второй год с того момента, когда в Рунете появился сайт SQL.RU и рассылка "MS SQL Server - дело тонкое…". Наш совместный с Александром Сибилёвым проект по-прежнему остаётся некоммерческим и по-прежнему медленно и неуклонно развивается… Многое удалось, а ещё больше из наших задумок не удалось воплотить в жизнь, но мы твёрдо верим, что сможем найти время для того, что бы сделать сайт и рассылку ещё более интересными и удобными для наших посетителей. Тем более, хочется выразить особенную нашу благодарность тем людям, которые помогали нам в этом деле, а особенно авторам статей, которые безвозмездно передали их для размещения в рассылке и на сайте. Это: Алексей Неупокоев, Алексей Шуленин, Вячеслав Брылёв, Глеб Уфимцев, Дмитрий Приходько, Сергей Забалуев и Сергей Снисаренко. Надеемся, что наше сотрудничество продолжиться и скоро появятся новые авторы, которые захотят поделиться своими знаниями и опытом с нашей уважаемой аудиторией, которая за прошедший год удвоилась и перевалила за десять тысяч. В качестве небольшого отчёта о проделанной за два года работе, предлагаю Вам ссылки на статьи, опубликованные за это время на сайте SQL.RU: Основы администрирования
Оптимизация эффективности исполнения запросов
Программирование доступа к данным из приложений
С уважением, Александр Сибилёв и Александр Гладченко …и очередной, направленный на Microsoft SQL Server вирус Worm.SQL.Spida закрывает оставленные нерадивыми DBA бреши в системе безопасности.
По сообщению на сервере viruslist.com ( http://www.viruslist.com/viruslist.html?id=272179 ), компьютерный червь
Worm.SQL.Spida.a., рассылается через серверы с установленным сервером Microsoft SQL. Червь получает доступ
к серверам, используя пароль "sa", устанавливаемый по умолчанию при установке сервера. При запуске червь
сканирует сеть и ищет компьютеры с доступным портом TCP 1433. Затем он пытается установить соединение
с этим компьютером и войти в систему с учетной записью системного администратора. Если соединение
проходит успешно, червь создает на атакуемой системе новую учетную запись пользователя Windows NT
"sqlagentcmdexec", создает для нее случайный пароль и добавляет в группе "Administrators" и "Domain Admins".
Далее червь получает доступные ресурсы для администратора на атакуемом компьютере и пытается копировать
себя в папку "system32" каталога установки Windows. Червь закрывает уязвимость, которая позволила ему
пробраться на компьютер. Для этого он устанавливает не пустой пароль учетной записи системного администратора.
Затем червь запускает себя уже на атакуемом компьютере.
XML в MS SQL Server 2000 и технологиях доступа к данным (продолжение) Автор: Алексей Шуленин
1. Введение 7. XML-представление наборов данных в ADO .NET На самом деле даже без провайдера SQLXMLOLEDB и SQLXML веб-релизов в Visual Studio .Net (точнее, в ADO.Net) имеются достаточно мощные средства для представления реляционных наборов данных в виде XML, и наоборот, XML в реляционном виде. Типовой сценарий работы выглядит следующим образом: получить внутри объекта DataSet таблицы как результаты запросов к источнику данных (возможно, к разным), связать их между собой на основе объектов DataRelation и создать XML-представление DataSet'a при помощи XmlDataDocument, как показано в Скрипте 6.
Результирующий XML можно видеть на рис.2.
По умолчанию из DataSet будет сгенерирован документ, в котором каждой записи DataRow соответствует
элемент с именем DataTable. Значения полей присутствуют в виде подэлементов DataRow с названиями
соответствующих полей DataColumns. Поскольку DataSet предполагает отсоединенный режим работы,
отношения между таблицами в источнике (в БД на SQL Server) не принимаются во внимание. Так, несмотря
на связывание таблиц в запросе:
(new OleDbDataAdapter("SELECT c.ContactName, c.ContactTitle, o.OrderDate FROM Customers c INNER JOIN Orders o ON c.CustomerID = o.CustomerID", Connection)).Fill(ds);
с точки зрения DataSet это плоское множество записей, потому что связи отработал сервер и прислал в DataSet
готовый табличный результат. Для образования иерархического XML-документа, где записи дочерней таблицы
являются вложенными элементами родительской, отношение между таблицами нужно указывать явно в
DataSet.Relations, при этом свойство .Nested объекта DataRelation должно быть выставлено в true. (Иначе записи
из родительской и дочерней таблиц будут перечислены друг за другом на одном и том же уровне иерархии).
Класс XmlDataDocument является производным от DOMовского XmlDocument, поэтому с его помощью над
DataSet'ом можно выполнять все стандартные XML-операции: XPath-запросы, XSL-преобразования и т.д.
Скрипт 7 демонстрирует, что данные источника можно модифицировать не только напрямую через DataSet
(ds.Tables[<Имя или номер таблицы в коллекции>].Rows[<Номер записи в коллекции>][<Имя или номер поля
в коллекции>] = …), но и через его XML-представление. В примере изменяются значений некоторых
XPath-узлов объекта XmlDataDocument. Эти изменения отражаются в DataSet'е, над которым построен данный
XmlDataDocument, а поскольку у соответствующих DataAdapter'ов таблиц определены UpdateCommand'ы, то
они будут транслированы далее в источник данных (SQL Server). Обратное тоже верно. Т.е. в DataSet можно
подгрузить XML-документ, который затем читать и модифицировать реляционными операциями. В Скрипте
8 мы получаем схему построенного в предыдущем примере XML-файла при помощи утилиты xsd.exe,
входящей в состав .NET Framework, читаем ее в XmlDataDocument и загружаем туда данные из этого документа.
На основе XSD-схемы ADO.Net создает DataSet эквивалентной реляционной структуры, так что становится
возможным обращаться и модифицировать XML-документ, как если бы он был совокупностью связанных
таблиц.
Неплохим иллюстративным примером было бы приложение, которое документирует пользовательские
библиотеки классов .Net в базе данных. Определения классов и объекты сохраняются в виде XSD-схем и
XML-документов (см. System.Xml.Serialization), а на их основе, в свою очередь, при помощи рассмотренного
соответствия реляционного и XML-представлений, которое обеспечивает ADO.Net, создается и наполняется
БД. В качестве самостоятельного упражнения вы можете попробовать сами написать такое приложение и
назвать его, скажем, Cheops.
8. Прямые XPath-запросы к объектам SQL Server
В Скрипте 7 было показано, как осуществлять XPath-навигацию по связанным таблицам в ADO.Net Dataset.
Подобным же образом XPath-запросы можно адресовать к SQL Server 2000, как если бы это был XML-ресурс,
а не сервер реляционных баз данных. Под словом "прямые" подразумевается, что эти запросы обращаются к
объектам базы данных напрямую, а не через аннотированные схемы, о которых речь пойдет в следующем
параграфе. В Скрипте 9 приведен запрос, выводящий всех клиентов с именами, начинающимися с букв X, Y, Z.
static void Direct_XPathQuery_SQLXML()
Обратите внимание на разное именование параметра в XPath-запросе и в параметрах объекта команды. Если
посмотреть, во что XPath превращается на сервере:
exec sp_executesql N' SELECT ContactName FROM Customers WHERE ContactName>=@НачБуква ', N'@НачБуква nvarchar(1)', N'X',
то видно, что первая @ автоматически получается из $ при переводе XPath-запроса в SQL, а о второй нужно
позаботиться самим в приложении (SqlXmlParameter.Name), иначе sp_executesql его попросту не поймет.
ПРОДОЛЖЕНИЕ СЛЕДУЕТ
Передача логинов и паролей между SQL серверами
По материалам статьи Microsoft:
INF: How To Transfer Logins and Passwords Between SQL Servers (Q246133)
Информация в этой статье относится к Microsoft SQL Server 7.0/2000 (все издания)
После перемещения базы данных в другой сервер, пользователи прежнего SQL сервера не смогут
подключиться к новому серверу. Это происходит потому, что на новом сервере отсутствуют логины этих
пользователей и их необходимо восполнить. В статье Microsoft Q246133 предлагается решение, которое
позволяет упростить процедуру передачи логинов на другой сервер и описываются наиболее типичные
проблемы, которые при этом могут возникнуть.
Msg 18456, Level 16, State 1
Вы должны передать логины и пароли на новый сервер.
Передача логинов и паролей между серверами SQL Server 7.0
SQL Server 7.0 Data Transformation Services (DTS) Object Transfer позволяет передавать логины и пользователей
между двумя серверами, но не предусматривает передачу паролей для аутентифицированных SQL Server
логинов. Чтобы передавать логины и пароли одного SQL Server 7.0 на другой, можно использовать
представленную ниже хранимую процедуру sp_help_revlogin. Эта процедура создаёт сценарий, который может
быть выполнен на новом сервере, где будут созданы логины с правильными SID и с установленными,
прежними паролями.
Чтобы передать логины и пароли SQL Server 7.0 на какой-нибудь экземпляр SQL Server 2000, или между двумя
экземплярами SQL Server 2000, можно использовать новый DTS Package Transfer Logins Task, входящий в
комплект SQL Server 2000. Для этого нужно:
1. Подключитесь к SQL Server 2000, на который необходимо перенести логины с паролями, и используйте
Data Transformation Services входящий в поставку SQL Server Enterprise Manager, разверните папку с таким же
именем в дереве нового сервера и щёлкните правой кнопкой мыши по Local Packages, а затем выберете New
Package.
ОБРАТИТЕ ВНИМАНИЕ: Вы можете использовать метод с DTS или представленный ниже
сценарий для передачи логинов между SQL Server 7.0 и SQL Server 2000, или между разными экземплярами
SQL Server 2000. Метод DTS может передать пароли, но не может передать оригинальные SID. Если логин
будет создан с отличным от оригинала SID и пользовательские базы данных также будут перемещены на
новый сервер, связь между пользователями базы данных и её логинами будет утеряна. Для передачи
оригиналов SID и предотвращения утери связи между пользователями и логинами, используйте
представленный ниже сценарий вместо метода DTS.
Скрипт перемещения логинов с паролями и оригинальными SID между SQL серверами
До применения представленного в этой главе скрипта, ознакомьтесь с находящимися в конце статьи
рекомендациями, которые представляют важные замечания и дополнения к способам применения
предлагаемых в настоящей статье способов переноса логинов, паролей и SID между SQL серверами.
1. Выполните представленный ниже скрипт на SQL сервере с которого необходимо перенести логины. Этот
скрипт создаёт два хранимых процедуры с именами sp_hexadecimal и sp_help_revlogin в системной базе данных
master. После успешного исполнения скрипта, выполните операции из пункта 2.
ОБРАТИТЕ ВНИМАНИЕ: Создаваемые в процессе исполнения скрипта процедуры напрямую
оперируют с системными таблицами SQL Server. Структура этих таблиц может изменяться от версии к версии
SQL Server, что может повлиять на работоспособность этого скрипта.
2. После того, как будет создана хранимая процедура sp_help_revlogin, запустите эту процедуру в Query Analyzer
на исходном сервере:
Хранимая процедура sp_help_revlogin может использоваться и на SQL Server 7.0 и на SQL Server 2000. Результат,
выводимый sp_help_revlogin, представляет собой готовый скрипт, который создаёт логины с оригинальными
SID и паролям. Сохраните выведенный в окно результатов исполнения скрипта текст, и затем выполните его
как скрипт в Query Analyzer на том SQL сервере, куда необходимо перенести логины
1. Внимательно проанализируйте создаваемый процедурой скрипт прежде, чем запустить его на SQL сервере,
куда необходимо передать логины. Если Вы должны передать NT логины на SQL сервер в другом домене,
отредактируйте сгенерированный процедурой sp_help_revlogin скрипт и замените имя старого домена новым
именем доменом во всех инструкциях sp_grantlogin. Поскольку логины в новом домене не будут иметь тот же
самый SID как у логинов в старом домене, связь пользователей базы данных с логинами будет нарушена.
Чтобы решать этих осиротевших пользователей, см. статьи, упомянутые ниже. Если Вы передаете NT логины
между SQL серверами в одном домене, будет использоваться тот же самый SID, и пользователь не должны
потерять связь со своими логинами.
Microsoft SQL-DMO (ODBC SQLState: 42000) Error 15023: User or role '%s' already exists in the current database.
Для получения инструкций о том, как разрешать проблему таких "осиротевших" пользователей, изучите
указанные ниже статьи Microsoft Knowledge Base. Для осиротевших SQL и NT логинов, см. статью:
INF: How to Resolve Permission Issues When a Database is Moved (Q240872)
Для получения информации о применении хранимой процедуры sp_change_users_login, которая перепривязывает
к логинам осиротевших пользователей (это касается только пользователей, потерявших связь со стандартными
SQL логинами), изучите следующую статью:
PRB: Troubleshooting Orphaned Users Topic in BOL Incomplete (Q274188)
3. Такой подход становиться возможным из-за параметра @encryptopt в системной хранимой процедуре sp_addlogin,
которая создаёт логин, используя зашифрованный пароль. Для получения дополнительной информации об этой
процедуре, см. тему в SQL Server Books Online: "sp_addlogin (T-SQL)".
Server: Msg 15025, Level 16, State 1, Procedure sp_addlogin, Line 56
Аналогично, если на новом сервере уже существуют логин с тем же самым SID, Вы получите ошибку:
Server: Msg 15433, Level 16, State 1, Procedure sp_addlogin, Line 93
По этой причине, очень важно тщательно изучить содержимое сгенерированного скрипта и таблицы sysxlogins,
что бы иметь возможность внести в его текст соответствующие изменения.
ССЫЛКИ НА СТАТЬИ
Новые технические статьи Microsoft
INF:
Statistics Used by the Query Optimizer in Microsoft SQL Server 2000 (White
Paper) (Q322096)
|
#099<< #100 |
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу |
В избранное | ||