SQL VIEW STATE. с 1.04

[Koteneff]

Чесно не понял я что с ним сделать. Это типа прав ddread ddwrite ddadmin ?

[alta_olg]

см. инструкцию ГТД Про (instr_GTD_PRO.doc в папке help_sql), стр. 20-21
g) В нижней части окна в строке «View server state» (в 2008 – «Просмотр состояния сервера») установить галочку в столбце «Предоставить»:

[Koteneff]

Все таки тему нужно продолжить.
У меня беда случилась, пришлось с нуля ставить сервер 2003 и sql 2005.
Для ускорения работы был применен простой метод: после установки sql 2005 выдернули все внутренности Акрониксом из старого бекапа.
Базы данных как и сервак успешно поднялись. Клиенты успешно прицепились.
Но в самих БД изменять что то у пользователей, которым открыт доступ к тем или иным БД сервер не дает. Хоть новых ползователей заводи с нуля.
А самое страшное что из серверных ролей самого сервера изчезла группа PUBLIC , которой мы назначали права View stat server.
Собственно сейчас на новом сервере все работают под старыми пользователями. View stat server если и назначен кому то, то я этого не вижу Но все работает. Вопрос, почему все работает и куда мог деваться PUBLIC с сервера? Причем PUBLIC есть в SECURITY в каждой БД но тоже не управляется никак.

[Koteneff]

UPD:

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

[popov]

Сервер живет нормальной жизнью, если с ним обращаться по-человечески!
Я вот не понимаю, что значит "после установки sql 2005 выдернули все внутренности Акрониксом из старого бекапа" и кто Вам вообще сказал, что так можно делать???
Вы сами себе проблем насоздавали, а теперь удивляетесь - смешно, чес слово.

Я так понимаю, что база master была притащена со старого сервера, может он другой редакции или другого SP или базы не через бэкап накатывались или еще по каким-то причинам, но похоже, что она получилась "битая", т.к. другого обяснения пропаже роли public у меня нет. Да и правам пользователей на доступ к БД деваться некуда особо - они в самой пользовательской БД живут...
Я думаю, что если нет культурных бэкапов БД со старого сервера (включая все системные), то надо сносить этот SQL, ставить заново (чтобы системные БД восстановить) и дальше разбираться с пользовательскими БД - если есть только mdf-ldf, то надо их "подключить" и обязательно переимпортировать в новую пустую БД, затем еще создать полнотекстовый индекс скриптом DATAfulltext.sql (он слетает при тупом переносе mdf-ldf).

А на будущее - любые переносы надо делать через бэкап - см. https://www.alta.ru/sql_backup_instr.php

[Koteneff]

Делалось это так:

С умирающего сервака (Win 2003 ) был снять Акрониксом бекап всего раздела.
Потом были заменены жесткие диски. Накатили Акрониксом чистую операционку.
Ручками установили SQL 2005. Остановили службы SQL. Акрониксом сняли образ с установленного SQL 2005 (что бы сохранить чистые системные базы).
Акроником из самого первого бекапа раздела вытащили один-в-один файлы SQL 2005 который стоял на старых жестких дисках. Это было с делано исключительно для экономии времени (слишком много аттачить пришлось бы БД). Не скажу что это страшно для сервера. У нас рассыпался RAID и рассыпался NTFS и мы теряли системные базы, но после двух таких крешей удавалось серверу SQL подснуть системные БД из последних образов системы и все работало. Это дало основание к тому что если положить все на свои места и всеже установленной операционке и сервере SQL то все будет работать.

Подняли службы, убедились что все поднялось. Что пользовательские базы данных работают, клиентам доступны, полнотекстовый поиск доступен.
Так же убедились что Public группа не присутствует в серверных ролях, а свойства моих пользователей не поддаются редактированию. Еще убедились что все работает без Public и без установленного разрешения на View state server ( хотя до переустановки все это в БД и на сервере это было (?) Вопрос в каких системных настройках (если не в системных БД) это храниться и почему все работает без этих разрешений. Или есть процессы не доступные мне ?

Если системная БД битая то сервер это отчетливо показывает, или вовсе не поднимает службу.
Культурный бекап я так понимаю тот который .bak и сделан из SQL сервера ?
Про переимпортировать я не понял. Аттач процедура простая.
А если для полнотекстового индекса FTC каталог подкладывать в SQL сервер при аттаче БД, это не помогает ?

[Koteneff]

UPD:

Снесли все что наработали за сутки. Накатили на сервер образ "чистой невинности" Чистая операционка+ свеже установленный SQL сервер. В серверной роли PUBLIC отсутствует. Ща конечно ручками все базы приаттачу и запущу скрипт полнотекстового поиска для каждой базы.

По ходу буду отписываться если еще встречу что нибудь любопытное.

[Koteneff]

Цитата: то надо их "подключить" и обязательно переимпортировать в новую пустую БД, затем еще создать полнотекстовый индекс скриптом DATA\fulltext.sql (он слетает при тупом переносе mdf-ldf).

При тупом переносе mdf-ldf не нужно запускать fulltext.sql ибо скрипт ругается следущим образом: A full-text index for table or indexed view 'dbo.Docs' has already been created.

хочется отметить, что в самой пользовательской БД сохраняется информация о существовании полнотекстового каталога. При аттаче БД сервер спрашивает и дает возможность подцепить его (если он есть конечно в наличии).

[Koteneff]

Дмитрий, хочется отдельно вас поблагодарить за участие. Разбор помог обратить внимание на состав полнотекстового каталога в разрезе файлов. И что мы подсунули на новый сервер старые каталоги, в которых были не все комплекты файлов. После последнихх крешов и чекдисков именно на некоторые файлы я помню ругался чекдиск при восстановлении. Теперь понятно почему слетел поиск.

Но отдельные вопросы по SQL VIEW STATE остались.

[popov]

Чисто теоретически конечно должно было прокатить то, что Вы описали, но лично я ни разу не видел какой-либо инструкции Microsoft, которая бы гарантировала, что так делать можно. Так что все это чисто на свой страх и риск...

Вообще странно конечно, т.к. серверные роли и их права, а также сами пользователи действительно живут в базе master. Вы ее на целостность проверяли (dbcc checkdb)? Акронис конечно вещь хорошая, но скорее всего он делал образ "на ходу" (когда SQL активно юзал свои файлы), поэтому что там в этом файле получилось - большая загадка (не верю я в такие "горячие бэкапы")...
Ну а то что при чистых системных базах роль public отсутствует это уже совсем необяснимо
Я бы на Вашем месте все-таки восстанавливал весь жесткий диск целиком (тем более если железка та же и только диск поменяли) - в этом варианте Акронис обычно хорошо рулит, хотя базы (mdf-ldf) все равно были в открытом состоянии...

[popov]

При тупом переносе mdf-ldf не нужно запускать fulltext.sql ибо скрипт ругается следущим образом: A full-text index for table or indexed view 'dbo.Docs' has already been created.

Согласен, не тот скрипт упомянул - надо ConvertFtcLng.sql

[Koteneff]

Откуда береться этот PUBLIC ? может сервер не правильно установили ? его то точно руками разворачивали.

[popov]

Откуда береться этот PUBLIC ? может сервер не правильно установили ? его то точно руками разворачивали.

Кто ж его знает откуда он берется? Может и установили "неправильно", хотя никакой такой опции при установке не бывает - это системная серверная роль, которая существует по определению, ее при всем желании удалить нельзя.
Возможно с ней то все в порядке (и права VIEW SERVER STATE для нее заданы), просто ее не видно в списке, а вот почему - загадка. Попробуйте подключиться к серверу под sa, потом под виндовым админом - возможно при входе кем-то из них с правами что-то не так...

[Koteneff]

Откуда береться этот PUBLIC ? может сервер не правильно установили ? его то точно руками разворачивали.

Кто ж его знает откуда он берется? Может и установили "неправильно", хотя никакой такой опции при установке не бывает - это системная серверная роль, которая существует по определению, ее при всем желании удалить нельзя.
Возможно с ней то все в порядке (и права VIEW SERVER STATE для нее заданы), просто ее не видно в списке, а вот почему - загадка. Попробуйте подключиться к серверу под sa, потом под виндовым админом - возможно при входе кем-то из них с правами что-то не так...

в самих пользовательских БД PUBLIC присутствует. server\databases\%databasename%\Security\Roles\Database Roles\public
под sa роль не появилась.
если посмотреть свойста пользователей server\Security\Logins\%user% в закладке Securables в таблице Securables пусто. Если добавить сервер то в permissions напротив View server state стоит Grantor'om пользователь sa c отмеченной галочкой. Т.е. view state server уже отдан. Как только делаешь ОК и выходишь из окна свойств и открываешь снова, опять в таблице Securables пусто (так должно быть или все таки выбор сервера с отметкой прав должна оставаться ?)

Вообщем резюмирая - сейчас все успешно работает.

[popov]

в самих пользовательских БД PUBLIC присутствует. server\databases\%databasename%\Security\Roles\Database Roles\public

Не путайте серверные роли с ролями в конкретных базах данных - это совсем разные объекты. Серверные роли надо искать в разделе "сервер/безопасность/серверные роли" - именно тому public можно дать view server state, а никак не роли в БД, т.к. это разрешение уровня всего сервера!

под sa роль не появилась.
если посмотреть свойста пользователей server\Security\Logins\%user% в закладке Securables в таблице Securables пусто. Если добавить сервер то в permissions напротив View server state стоит Grantor'om пользователь sa c отмеченной галочкой. Т.е. view state server уже отдан. Как только делаешь ОК и выходишь из окна свойств и открываешь снова, опять в таблице Securables пусто (так должно быть или все таки выбор сервера с отметкой прав должна оставаться ?)

Да, это всегда так - такой вот "дружественный" интерфейс от M$
Если всем логинам сервера (которые ходят в базу ГТД) индивидуально предоставлен view server state, то этого вполне достаточно - серверную роль public можно и не мучить. Хотя куда она могла деться - загадка конечно.

Вообщем резюмирая - сейчас все успешно работает.

Ну и отлично! Однако для всех остальных:

ЛЮДИ! НИКОГДА НЕ ДЕЛАЙТЕ ПЕРЕНОС БАЗ ДАННЫХ ТАК, КАК ЭТО СДЕЛАЛ KOTENEFF!!! Без крайней на то необходимости (только если не останется другого варианта вследствии краха системы).
Вариант с прямым переносом файлов mdf/ldf возможен только при условии, что они копировались после полной остановки всех служб SQL-сервера и если версия SQL-сервера совпадает с точностью до билда (x.y.zzzz). А то недавно был прецедент, что товарищ умудрился перетащить mdf/ldf с SQL2005 на SQL2008 в итоге полностью потерял базу
Любые переносы надо делать с помощью бэкапов (https://www.alta.ru/sql_backup_instr.php), в т.ч. и для системных баз (для восстановления master надо будет запустить службу SQL-сервер в однопользовательском режиме - см. хелп SQL-сервера)...