Добрый день всем !

Поставил тут недавно на MS Windows 2019 Essentials - 64 bit сиё чудо программного обеспечения MSSQL 2019 - 64 bit сервер.
Встало сиё чудо программного обеспечения без ошибок. Создал в нем базы данных. Как будто все работает нормально.
Данные из баз извлекаются и соответственно заносятся туда. То есть базы работают нормально. Казалось бы живи и радуйся, но не тут то было.

1. В системный лог Windows 2019 Essentials стала "валиться" ошибка

Параметры разрешений для конкретного приложения не дают разрешения Локально Активация для приложения COM-сервера с CLSID
{571FCE7E-C4EB-41CF-B9D1-1CBCBFC6D2BD}
и APPID
{82F02F0C-0E3A-472E-BAA5-0BC0AE548818}
пользователю NT SERVICE\SQLSERVERAGENT с ИД безопасности (S-1-5-80-344959196-2060754871-2302487193-2804545603-1466107430) и адресом LocalHost (с использованием LRPC), выполняемого в контейнере приложения Недоступно с ИД безопасности (Недоступно). Это разрешение безопасности можно изменить с помощью средства администрирования служб компонентов.

Понятно что это ошибка от DistributedCOM и понятно как ее исправлять. Только не понятно где взять пользователя NT SERVICE\SQLSERVERAGENT ? У меня на сервере такого пользователя нет ? Как его найти ?

2. Настроил планы обслуживания, а именно Полный бэкап баз данных в определенное время это одно задание. При запуске ручками оно выполняется успешно и без ошибок.
Далее настроил второе задание. Это естественно бэкап логов транзанкций. Причем взял бэкап логов транзанкций как базы model, так и всех своих баз данных. Бэкап лога танзанкций базы model проходит успешно, а вот бэкап логов транзанкций моих баз данных не проходит и выдается нижеследующая ошибка (показана на примере одной моей базы данных, чтобы уменьшить лог)

Microsoft(R) Server Maintenance Utility (Unicode) Version 15.0.2000
Отчет был сформирован на "OCTAGON".
План обслуживания: Transanctions_Backup
Продолжительность: 00:00:00
Состояние: Внимание! Не удалось выполнить одну или несколько задач.
Подробности:
Резервное копирование базы данных (журнал транзакций) (OCTAGON)
Создать резервную копию базы данных на Соединение с локальным сервером
Базы данных с уровнем совместимости 70 (SQL Server версия 7.0) будут пропущены.
Базы данных Все базы данных
Тип: Журнал транзакций
Добавить к существующему
Начало задачи: 2022-01-25T16:00:00.
Конец задачи: 2022-01-25T16:00:00.
Ошибка:(-1073548784) Сбой выполнения запроса "BACKUP LOG [acc_npf_ed] TO DISK = N'E:\\backup\\DB1..." со следующей ошибкой: "Инструкцию BACKUP LOG невозможно выполнить, так как не существует резервной копии текущей базы данных.
BACKUP LOG прервано с ошибкой.". Возможные причины сбоя: проблемы с этим запросом, свойство "ResultSet" установлено неправильно, параметры установлены неправильно или соединение было установлено неправильно.

Команда:EXECUTE master.dbo.xp_create_subdir N''E:\backup\DB1C8Backup\Tran\model''
GO
EXECUTE master.dbo.xp_create_subdir N''E:\backup\DB1C8Backup\Tran\acc_npf_ed''

GO
BACKUP LOG [model] TO DISK = N''E:\backup\DB1C8Backup\Tran\model\model_backup_2022_01_25_160000_8840128.trn'' WITH NOFORMAT, NOINIT, NAME = N''model_backup_2022_01_25_160000_8840128'', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10

GO
BACKUP LOG [acc_npf_ed] TO DISK = N''E:\backup\DB1C8Backup\Tran\acc_npf_ed\acc_npf_ed_backup_2022_01_25_160000_8840128.trn'' WITH NOFORMAT, NOINIT, NAME = N''acc_npf_ed_backup_2022_01_25_160000_8840128'', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10

GO

Пробовал делать полную копию своих баз данных - НЕ ПОМОГАЕТ, без оных тоже - НЕ ПОМОГАЕТ
Пробовал сжатие, без сжатия резервной копии баз данных - НЕ ПОМОГАЕТ
Пробовал пути к папке куда идет бэкап указывать со слЭшами и без слЭшев - НЕ ПОМОГАЕТ

Ткните носом куда надо копать ?
Заранее спасибо за помощь

aleks222, Спасибо за ответ ! Еще бы хорошо было бы если бы Вы внимательно прочитали моё сообщение. А в нем сказано что ПОЛНЫЙ БЭКАП базы я сделал, перед тем как делать бЭкап логов транзакций. Это не помогло. Внимательнее надо читать то что написано. А не пушить попусту пальцы веером. Это первое.
И второе. После ночи, а вечером был сделан бЭкап полный баз данных, чудесным образом стали бЭкапится и логи транзакций. Вывод отсюда можете сделать ? Я уже сделал....

Третье. Что-то можете сказать по первому пункту моего сообщения, кроме пушения пальцев веером ?
Заранее спасибо

Понятно, что эта ошибка не мешает нормальной работе сиего чуда программного обеспечения, но все же неприятно что она "валится" в лог системы

Владислав Колосов, Спасибо за ответ и совет. Читаю доки на это чудо от микрософта аж начиная с MSSQL 2000 (кстати, там планировщик заданий удобный)Б MSSQL 2008, MSSQL2014, и вот теперь познакомился и сим чудом программного обеспечения под названием MSSQL 2019. Принцип везде один и тот же. Нового ничего нет кроме всякой лабуды, которая используется малым количеством народа. Как уже сказал планировщик самый удобный в MSSQL 2000 тот сразу все начинает бЭкапить, что естественно настроено в качестве заданий. И нет никакой монстровости....Это так лирика... Ответ на первый мой вопрос посмотрите что я написал для пользователя aleks222

Можете что-то сказать по первому моему вопросу ?
Заранее спасибо

Понятно, что эта ошибка не мешает нормальной работе сиего чуда программного обеспечения, но все же неприятно что она "валится" в лог системы

SQL2008, Как ни странно, но мелкософт еще знает что такие наверняка есть. И для них НЕ предлагает бЭкапить логи транзакций...А почему мелкософт упоминает об этих базах надо спросить у него.

Спасибо за ответ и помощь. Оно то оно да не совсем. Народ Вы читаете первое сообщение или нет ? Там же ясно написано, что это сообщение в лог системы "валит" DistributedCOM. И там написано что мне известно как его настраивать. НО не понятно где найти пользователя NT SERVICE\SQLSERVERAGENT ? У меня на сервере такого пользователя нет ? Как его найти ?
А так в приведенной Вами ссылке все написано верно, как дать права этому пользователю. Я это и сам давно знаю

Спасибо за ответ и помощь. Глянул доку, так и есть. Да я и раньше догадывался что что-то такое и происходит. Просто думал что при установке MSSQL даст все необходимые права этому виртуальному пользователю. А они в мелкософт так не считают и говорят что этому пользователю надо давать как можно ограниченные права (в той же доке об этом и написано). И получается что мелкософт как всегда перебдел с безопасностью НО налете на ошибки в DistributedCOM. Странно, очень странно. Навроде и Windows 2019 Server и MSSQL 2019 разработан одной и той же конторой, а получается что левая нога не знает что делает правая....еще раз убеждаюсь что микрософт с его продуктами это кровавая месть всему человечеству...это так достало...
Решить данную проблему можно изменив запуск службы SQL Agent-а например от пользователя Оператор баз данных....тока зачем ?...это надо будет перестроить
1. Изменить NT SERVICE\SQLSERVERAGENT на оператор баз данных с помощью SQl Server Configuration Manager с последующим перезапуском этой службы, а лучше всех
2. Дать этому пользователю соответствующие права как на папки резервного бэкапирования, так и настроив права для этого пользователя в DistributedCOM. После настройки этих прав сервер должен будет перезагрузиться. Можно конечно это сделать вечером когда нет юзеров. Но стоит ли оно того ? Наверно лучше оставить пусть "валится" эта ошибка в лог, тем более что она ничему не мешает.

Спасибо за ответ и наставление на путь истинный. Спасибо за помощь. Глянул доку, так и есть. Да я и раньше догадывался что что-то такое и происходит. Просто думал что при установке MSSQL даст все необходимые права этому виртуальному пользователю. А они в мелкософт так не считают и говорят что этому пользователю надо давать как можно ограниченные права (в той же доке об этом и написано). И получается что мелкософт как всегда перебдел с безопасностью НО налете на ошибки в DistributedCOM. Странно, очень странно. Навроде и Windows 2019 Server и MSSQL 2019 разработан одной и той же конторой, а получается что левая нога не знает что делает правая....еще раз убеждаюсь что микрософт с его продуктами это кровавая месть всему человечеству...это так достало...
Решить данную проблему можно изменив запуск службы SQL Agent-а например от пользователя Оператор баз данных....тока зачем ?...это надо будет перестроить
1. Изменить NT SERVICE\SQLSERVERAGENT на оператор баз данных с помощью SQl Server Configuration Manager с последующим перезапуском этой службы, а лучше всех
2. Дать этому пользователю соответствующие права как на папки резервного бэкапирования, так и настроив права для этого пользователя в DistributedCOM. После настройки этих прав сервер должен будет перезагрузиться. Можно конечно это сделать вечером когда нет юзеров. Но стоит ли оно того ? Наверно лучше оставить пусть "валится" эта ошибка в лог, тем более что она ничему не мешает

Socrates, Огромное спасибо всем ответившим. Было очень приятно получить наставление на путь истинный. Если кого-то нечаянно обидел, приношу извинения. Тему можно считать закрытой.

Только в качестве реплики.....полагать можно бабенку на кровать остальное все надо уметь делать, а главное уметь читать.....я всегда умилялся людям которые смотрят в книгу а видят фигу....они увидели первые пару букв и уже кричат что они умеют и знают все...однако на самом деле ничего не умеют и не знают, кроме как пушить пальцы веером, при этом оскорбляя совершенно незнакомых людей....как говаривалось в одном фильме..."Я думал тут ас, а тут У 2-С"....

Клоун вообще-то уважаемая во всем мире профессия, только не в вашем случае.....
На остальной бред отвечать нет смысла.....

Спасибо за мысль и предложение. Уже проверил. Все нормально откатывается на заданный момент времени с помощью журналов транзакций.
Меня взбесили то что когда я сделал полный бЭкап, то сие чудо программного обеспечения никак это не отметило у себя что сделан полный бЭкап и надыть начинать делать логи транзакций....А это чудо программного обеспечения заносит к себе в базу только те бЭкапы, которые выполняет сам в качестве настроенного задания....а это в корне не верно...