Що ви робите, буде залежати від вашої версії SQL Server, а також від того, чи можете ви дозволити зняти послугу SQL Server для встановлення нових облікових даних. Перші два способи тут не вимагають перезавантаження екземпляра:
Для екземплярів SQL Server 2005, 2008 та 2008 R2
Ви можете підключитися за допомогою NT AUTHORITY\SYSTEM
облікового запису (або інших методів зворотного доступу). У деяких відповідях тут є деякі деталі:
У мене також є підказка на MSSQLTips.com, яка стосується цієї проблеми:
По суті, ви завантажуєте PSExec від Microsoft, а потім використовуєте його для запуску Management Studio після встановлення:
PsExec -s -i "C:\...\Ssms.exe"
Це підключиться як NT AUTHORITY\SYSTEM
і дозволить вам робити такі речі в Провіднику об’єктів, як:
Змініть примірник на режим SQL Server та Windows Authentication - клацніть правою кнопкою миші ім’я сервера, натисніть властивості та змініть перемикач, якщо він наразі встановлений лише для Windows:
Встановіть пароль для sa
облікового запису - розгорніть Безпека, розгорніть Логіни, клацніть правою кнопкою миші sa
та натисніть Властивості, і в діалоговому вікні, що з’явиться, буде два поля для введення пароля:
Додайте власний логін якsysadmin
- клацніть правою кнопкою миші Логін, Новий логін ... введіть своє ім’я для входу (у формі DOMAIN\username
), потім перейдіть на вкладку Ролі сервера та поставте sysadmin
прапорець і натисніть кнопку ОК:
(або, якщо ваш логін вже вказано, клацніть правою кнопкою миші, Властивості та переконайтесь, що sysadmin
прапорець встановлено в розділі Ролі сервера)
Для SQL Server 2012 та новіших екземплярів
Починаючи з SQL Server 2012, NT Authority\SYSTEM
за замовчуванням більше не було надано прав на SQL Server. Тож ще один спосіб зробити це в цих нових версіях Арґеніс Фернандес :
- Якщо служба SQL VSS Writer запущена, зупиніть її та призупиніть всі плани технічного обслуговування або програмне забезпечення для резервного копіювання сторонніх виробників, які можуть на неї покладатися.
Відкрийте regedit.exe
та змініть значення, на HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SQLWriter\ImagePath
яке вказуватимете SQLCMD.exe
, в яке збирається C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\**<...110|120|130|140...>**\Tools\Binn
. Після редагування значення реєстру має виглядати приблизно так (вибачте за прокрутку):
"C:Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\SQLCMD.exe" -S .\instancename -E -Q "ALTER ROLE sysadmin ADD MEMBER [YourDomain\YourUserName];"
Спробуйте запустити службу SQL VSS Writer знову (ви отримаєте помилку; це нормально).
Тепер ви зможете підключитися як sysadmin
користувач YourDomain\YourUserName
. Тому зупиніть службу SQL VSS Writer, виправте реєстр та перезапустіть службу (якщо вона потрібна для запуску або якщо вона запускалася до того, як ви її запустили).
Я переглянув це набагато детальніше у другій підказці:
Хоча коли я писав цю пораду, я застосував більш громіздкий підхід зробити копію SQLCMD.exe
та замінити sqlwriter.exe
- набагато простіше просто вказати службу SQLCMD.exe
безпосередньо.
Якщо ви можете дозволити собі зняти послугу SQL Server
Існує офіційно підтримуваний шлях від Microsoft, який вимагає перезапустити екземпляр в режимі єдиного користувача:
Існує також функція в dbatools.io , рішення Powershell для управління SQL сервером, яке називається Reset-DbaAdmin
:
Безпека - це не головне питання
Я бачу безліч людей, які закликають Microsoft "виправити" ці так звані "вразливості". Це дійсні підходи до відновлення доступу до екземпляра SQL Server, яким ви належним чином володієте. Всі вони вимагають підвищених привілеїв на фізичному хості, де проживає SQL Server; як я вже говорив декільком людям, якщо ви не хочете, щоб розробники возилися зі встановленнями SQL Server, не робіть їх адміністраторами.