Как я восстанавливал разрушенную базу

21.08.15

База данных - Архивирование (backup)

УТ10.3 на Платформе 8.2 на базе MSSQL была разрушена после попытки её восстановить после неудачного динамического обновления.
Таблица Config целевой базы была заменена на содержимое таблицы Config от другой рабочей базы.
Но на самом деле конфигурации у них существенно отличались, поэтому после таких действий целевая база рухнула окончательно.
Что же делать?

ДИСКЛЕЙМЕР

Автор не несет никакой ответственности, кроме как за достоверность предоставленной информации.
Всю нижеследующую информацию воспринимать и использовать на свой страх и риск. 

ПРЕДЫСТОРИЯ

Ситуация досталась мне в следующем виде.

Разрушенная база (её имя для конкретики UTn) - это узел РИБ, который не обменивался с центром с марта 2015. Конфигурация, соответственно, тоже мартовская.

Рядом (на этом же сервере) живая база РИБ (имя UT), конфигурация которой актуальна. 

При возникновении проблем в базе UTn - на уровне СУБД была перенесена таблица Config из базы UT

Но так делать нельзя было, так как это внутренние релизы конфигураций с разницей почти в полгода, а значит, таблицы Config и структуры таблиц с данными на уровне SQL существенно отличались.

Мало того - копии не создавались автоматически, и коллега не потрудился создать копию вручную перед выполнением столь рискованного скрипта (по переносу конфигурации на уровне SQL).

И мы получили следующее:

  1. Разрушенная база
  2. Эта база важная, восстановить надо любой ценой
  3. Нет ни одной копии, даже старой 
Таким образом, мне несказанно повезло поисследовать внутренние механизмы и сделать нечто необычное и интересное :)

Симптомы на уровне 1С

Первое, что я увидел при запуске Предприятия 

Тип не определен <некий GUID> 
Завершить перезапустить... 
Тип не определен 

Конфигуратор доступен, открывается, но при попытке внести любые изменения (точней, обновить конфигурацию ИБ) - валится с записью дампа

ЛЕЧЕНИЕ, РЕМОНТ и ТАНЦЫ С БУБНОМ

Неудачные попытки 

По привычке пробовал чистить ConfigSave - не помогло

Пробовал обновить ConfigSave из Config - не помогло

Чистить кеш и всякое такое

"Тестирование и исправление" - запись дампа почти сразу

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

Как я встал на верный путь

Попробовал пойти тем же путем, которым база была поломана, а именно: скопировать Config из разных живых баз от разных дат и на разных серверах

Конечно, идеально подошла бы любая база от даты, когда остановился обмен между разрушенной базой и центром РИБ, тогда бы структура таблиц на уровне SQL и содержимое таблицы Config было бы подходящим. Но такой не нашлось.

После слепого шаманства неопределенное время я в итоге получил ошибку "В схеме базы данных отсутствует таблица..."

Увидел в SQL-студии таблицу DBSchema, с одной строкой и одной колонкой, в которой какое-то сериализованное значение, которые непонятно как развернуть, некий черный ящик. Сделал поиск про эту таблицу в официальном партнерском форуме 1С для специалистов. Наткнулся на опыт, где восстановить работоспособность базы помогла замена содержимого битой базы в таблицах Config, Params и DBSchema на содержимое из аналогичных таблиц живой базы.

Ближайшая база под рукой была вышеупомянутая UT. Разница между конфигурациями живой и битой баз - несколько месяцев. Попробовал..

Иии... БИНГО!

Помогло! Ошибки в конфигураторе изменились, причём на более понятные. Режим предприятия открылся, но формы мало каких объектов открывались, возникали ошибки уровня SQL. Вполне ожидаемо, что SQL "не видел" каких-то реквизитов в таблицах, а какие-то были, наоборот, лишними, но уже было понятно, с чем работать.

Попытка оптимизировать процесс, взяв более "близкую" копию

Пришла идея повторить способ с другими базами, то есть взять копии, чтоб дельта между датами живой и битой базы была поменьше. Но так как базы большие и на этом удаленном сервере - то ли канал был загружен, то ли в принципе узкий, решил не таскать базы целиком, а создать на местах с подходящими копиями отдельную чистую базу SQL, в которую руками перенести эти 3 служебные таблицы из развернутых копий, и эти маленькие промежуточные базы (где только 3 таблицы) уже заархивировать, и их переносить на удаленный сервер с проблемной базой. К сожалению, этот способ у меня не сработал, возможно, я что-то сделал неверно при переносе таблиц ConfigParams и DBSchema в промежуточную базу SQL. В самом конце, в конфигуратор либо предприятие войти не получалось, 1С сообщал что конфигурация разрушена, предлагал починить, но безуспешно.

"Долгая дорога в дюнах" или "Рутина, в студию!" [ПРЕДИСЛОВИЕ]

В итоге, я вернулся к варианту переноса этих 3 конф. таблиц из живой базы на том же сервере, пусть и разница между внутренними релизами конфигураций была несколько месяцев. Зато конфигуратор и предприятие открывались, а ошибки если и были - были понятными и разрешимыми, хотя и неясно куда всё это приведёт.

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


ЭПИЛОГ К ПЕРВОЙ ЧАСТИ

Если тебе интересно продолжение с техническими подробностями, и также краткий курс по SQL для 1С-специалиста - ставим звезду! Чем больше будет людей, которым интересно - тем интересней мне будет этим заниматься, а значит, быстрей, полней и качественней подготовлю и опубликую! Критика, вопросы и пожелания - в комментарии, пожалуйста!

Успехов! И не ленитесь сделать SAVE перед прыжком в пропасть ;)

 


UPD Продолжение последовало

MSSQL lowlevel

См. также

SALE! 10%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием Россия Платные (руб)

Продано более 270 раз! Обработка позволяет перенести из УПП в ERP / 1С:УТ 11 / КА 2 всю возможную информацию. Переносятся документы, а также начальные остатки и справочная информация. Типовая обработка от фирмы 1С не позволяет сохранить документы за период работы. Кроме того, наши алгоритмы выгрузки начальных остатков тоже имеют больше функционала и тщательно проверялись на реальных проектах перехода с УПП на ERP. Наша разработка будет полезна как фирмам-франчайзи, которые периодически выполняют перенос данных для заказчиков, так и организациям, самостоятельно выполняющим проект по переходу. При приобретении обработки вы будете четыре месяца получать ее обновления, далее можно приобрести подписку на обновления. Конфигурации 1С постоянно меняются, выходят новые релизы. Имея подписку на обновления, вы всегда можете быть уверены, что правила конвертации данных будут работать на ваших базах 1С.

50722 45650 руб.

04.08.2015    155896    289    263    

331

SALE! 10%

Перенос данных из УПП 1.3 / КА 1.1 в БП 3.0

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием Россия Бухгалтерский учет Платные (руб)

Предлагаем перенос данных из УПП 1.3 в БП 3.0 (или из КА 1.1 в БП 3.0). Переносятся документы, начальные остатки и вся справочная информация. Есть фильтр по организации и множество других параметров выгрузки. Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов. Перенос данных возможен в 1С: Бухгалтерию 3.0 версии ПРОФ, КОРП или базовую. Переход с "1С: Управление производственным предприятием 1.3" / "1С:Комплексная автоматизация 1.1" на "1С:Бухгалтерия предприятия 3.0" с помощью наших правил конвертации будет максимально комфортным! Обработка входит в ТОП продаж Инфостарта!

43889 39500 руб.

25.02.2015    166976    282    236    

367

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 руб.

12.06.2017    131727    687    290    

379

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С: Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила тестировались на конфигурациях УПП 1.3 (1.3.215.x) и БП 3.0 (3.0.144.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    18239    114    36    

69

SALE! 10%

Перенос данных из ERP 2 / КА 2 в ЗУП 3

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Управленческий учет Платные (руб)

Наша обработка позволяет не только перенести все документы, справочную информацию и начальные остатки из ERP 2 или КА 2 в ЗУП 3, но и организовать регулярный перенос данных между программами 1С:ERP 2 / КА 2 и 1С:ЗУП 3. Вы можете выбрать период отбора данных и установить фильтр по организациям, чтобы выгружать только необходимую информацию. Более того, перенос оперативно обновляется при выходе новых релизов программы 1С, так что вы всегда будете иметь самую актуальную версию обработки.

48278 43450 руб.

03.12.2020    32690    68    56    

69

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11 / КА 2 / ERP 2 (ЕРП 2)

Обмен между базами 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Предлагаем вам качественное и проверенное временем решение для перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2. Перенос данных находится в продаже с 2015 года, постоянно развивается, им воспользовались уже более 240 компаний. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам. При выходе новых релизов конфигураций 1C оперативно выпускаем обновление переноса данных.

50722 45650 руб.

24.04.2015    188239    264    235    

267

SALE! 10%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос позволяет настроить собственный обмен данными между указанными программами, альтернативный предлагаемому фирмой 1С. Перенос данных осуществляется из 1С:ERP 2 / 1С:КА 2 / 1С:УТ 11 в 1С:БП 3.0. Правила обмена оперативно обновляются при выходе новых релизов программы 1С, так что вы всегда будете иметь самую актуальную версию обработки.

38500 34650 руб.

15.04.2019    66143    164    131    

97

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. За основу были взяты стандартные правила переноса остатков и справочной информации. Правила тестировались на конфигурациях УТ 10.3 (10.3.85.x) и УТ 11.5 (11.5.15.x).

28000 25200 руб.

23.07.2020    43326    185    63    

138
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TODD22 18 21.08.15 19:45 Сейчас в теме
УТ10.3 на Платформе 8.2 на базе MSSQL была разрушена после попытки её восстановить после неудачного динамического обновления.

Сам сломал, сам чиню... на инфостарт статью пишу....

Уже наверное не первая статья на тему "неудачно динамически обновились"... И всё равно продолжают динамически обновлять.... Ни чему людей жизнь не учит.
Stocker+; Alien_job; dmpas; DoctorRoza; ojiojiowka; +5 2 Ответить
6. bforce 480 23.08.15 15:41 Сейчас в теме
(1) TODD22, я обновлял и буду обновлять, так как соблюдаю правила и готов к возможным ошибкам (знаю как лечить). Мне лично непонятно слепое отрицание динамического обновления без попытки разобраться что к чему.
sasha777666; John_Dow; swiss-garant; VasMart; METAL; poisonapple; Артано; +7 Ответить
7. TODD22 18 23.08.15 16:19 Сейчас в теме
(6) bforce, Обновляй кто тебе запрещает?
Мне лично непонятно слепое отрицание динамического обновления без попытки разобраться что к чему.

Разобраться в чём? Если есть вероятность того что что то будет испорчено динамическим обновлением проще от него отказаться чем разбираться.
Мне лично на работе есть чем заняться. Если есть на работе свободное время ломать базы а потом героически по 3 дня разбираться что к чему и как это починить я рад за вас.
У меня к сожалению 100+ розничных торговых точек торгующих практически круглосуточно. И простой центральной базы хотя бы 1 день несёт в себе невероятные проблемы.

Разговор не о том что кто то "слепо отрицает" а о том что динамическое обновление периодически подкидывает проблем и периодически появляются статьи как эти проблемы исправлять.
Я то же сталкивался с проблемами после динамического обновления. Для меня проще от него отказаться в принципе чем потом заниматься восстановлением и ремонтом баз. Я лучше полезный и нужный функционал в конфигурации буду развивать.
8. bforce 480 23.08.15 16:48 Сейчас в теме
(7) TODD22,
героически по 3 дня разбираться что к чему и как это починить я рад за вас
Радуйтесь! Никогда больше 3 минут решение вопроса не занимало. Все возможные проблемы уже давно до вас все выловили и описали как лечить, а вы похоже просто не хотите этого осознать. Все остальное, что у вас написано - это вывод из первого предположения.
10. TODD22 18 23.08.15 17:03 Сейчас в теме
(8) bforce,
Никогда больше 3 минут решение вопроса не занимало.

Да ладно... И столько статей на ИС. Автор статьи явно не в 3 минуты с решением уложился.
Все возможные проблемы уже давно до вас все выловили и описали как лечить, а вы похоже просто не хотите этого осознать.

Я предпочитаю не создавать себе проблем.
по вашей логике стоит отказаться и от платформы вообще

Я такого не писал. Так что это ваша логика. И довольно странно додумывать за других.
обычная практика - это попытаться понять причину и предложить "способ обхода" ошибки.

Обычная практика это не создавать себе проблем.
Способ обхода всех ошибок связанных с динамическим обновлением это по возможности им не пользоваться. Всё остальное это не способы обхода ошибок, а исправление последствий.
9. bforce 480 23.08.15 16:53 Сейчас в теме
(7) TODD22,
проще от него отказаться чем разбираться
по вашей логике стоит отказаться и от платформы вообще, потому что в ней есть ошибки, в которых не хочется разбираться. В то же время, обычная практика - это попытаться понять причину и предложить "способ обхода" ошибки.
13. METAL 283 23.08.15 21:26 Сейчас в теме
(1) TODD22, статья не о том, кто сломал и стоит ли делать бекапы. Но вообще-то сломал не я :)
14. TODD22 18 24.08.15 05:31 Сейчас в теме
(13)
статья не о том, кто сломал и стоит ли делать бекапы. Но вообще-то сломал не я :)

На работу в одну организацию устроился там бэкапы делались выгрузкой dt файла. При том что база на СУБД.
При этом программист утверждал что он крутой специалист и что он всё правильно сделал и делать бэкапы выгрузкой dt файла это правильно.
2. DoctorRoza 22.08.15 13:42 Сейчас в теме
Возможно, что автор как раз и исправляет за горе-администратором - программистом!
16. METAL 283 24.08.15 09:03 Сейчас в теме
(2) DoctorRoza, "не ошибается тот, кто ничего не делает" ;) На самом деле, я категорически благодарен коллеге за создание такой ситуации, и подаренную мне возможность исследовать платформу и SQL на данном уровне.
3. DoctorRoza 22.08.15 13:44 Сейчас в теме
Автор! Добавьте по-больше скриншотов для наглядности! ;)
15. METAL 283 24.08.15 08:30 Сейчас в теме
(3) DoctorRoza, обязательно, как только найдётся время, постараюсь на этой неделе.
(4) vasyak319, а с чего Вы взяли, что безуспешно?
18. vasyak319 149 24.08.15 10:21 Сейчас в теме
(15) с того, что об этом ваша статья.
19. METAL 283 24.08.15 10:54 Сейчас в теме
(18) vasyak319, интересно взглянуть на фрагмент, который привёл Вас к такому выводу. Стоит отметить, неверному. Потрудитесь процитировать?
20. vasyak319 149 24.08.15 18:06 Сейчас в теме
(19) Ваша статья кончается вот этим:
ошибки если и были - были понятными и разрешимыми, хотя и неясно куда всё это приведёт
т.е. итог - получение глючной и стрёмной базы. Восстановление с таким результатом это и есть "безуспешно".
21. METAL 283 25.08.15 16:06 Сейчас в теме
(20) vasyak319, экий Вы пессимист :) Из неопределенной фразы делаете вывод в худшую сторону. Восстановленная база работает вполне надёжно.
4. vasyak319 149 22.08.15 14:13 Сейчас в теме
Называйте статьи правильно: "Как я безуспешно восстанавливал разрушенную базу".
5. Craig 274 23.08.15 10:28 Сейчас в теме
like за колоссальную работу! Когда у самого случилась такая фигня, убил не мало времени и сил. К сожалению не полностью удалось восстановить (((
11. DoctorRoza 23.08.15 19:57 Сейчас в теме
А вот тут уже тянет на философский диспут: "Какое качество специалиста является более ценным: недопущение ошибок в работе или умение грамотно/быстро устранять возникающие ошибки?" :)

p.s.
Тоже отказался от димано, выполняю ее только, если уже совсем деваться некуда.
12. TODD22 18 23.08.15 20:14 Сейчас в теме
недопущение ошибок в работе или умение грамотно/быстро устранять возникающие ошибки?" :)

ИМХО недопущение ошибок. Специалист который создаёт ошибки а потом их грамотно/быстро устраняет будет заниматься тем что будет создавать ошибки и затем с ними бороться. Вместо выполнения полезной работы.

Вот бы у нас в отделе кто нибудь из программистов ломал бы базу а потом садился бы "быстро/грамотно" её восстанавливать. Я думаю он бы много о себе нового узнал от коллег.

А вообще интересный такой момент. Сейчас для одной компании делаю интеграцию их сервиса с 1Ской. Этим сервисом с недавних пор пользуется Яндекс и получает от туда данные для своих нужд.
Там невероятно жёсткие требования к работе баз, к доступности и стабильности и всё это прописано в договорах. Там за подход "если не проканает то я наверное починю" увольняют сразу.
И там в голову никому не приходит делать такие вещи. Зато среди 1Сников нормальная практика ломать, а потом чинить.
Я им предложил добавить регламентное задание на стороне их сервера для обмена с 1Ской очень много нового узнал о требованиях к стабильности сервисов и тд. Там каждую лишнюю функцию нужно обосновывать и очень серьёзно.
Казалось бы можно всё организовать, обкатать сервис и тд. Но нет... Цена ошибки очень велика и то же прописана в договоре.
ojiojiowka; +1 Ответить
17. METAL 283 24.08.15 09:04 Сейчас в теме
Уже наверное не первая статья на тему "неудачно динамически обновились"

Коллеги, данная статья НЕ посвящена вопросам динамического обновления, еще раз история такая:
  • Возникла какая-то вполне рядовая проблема с конфигурацией узла РИБ (динамическое обновление, ошибка кэша или что-то еще - не суть)
  • Попытка решить п.1 с помощью неподходящего скрипта в SQL, который разрушил базу
  • Пришлось разбираться с тем, что есть, и восстанавливать любыми средствами, так как архива для восстановления не было
Незначительная часть данных была потеряна, базу удалось оживить, сейчас работает.
Здесь я бы хотел поделиться приёмами, которые позволили это сделать.
Несколько позже оформлю продолжение
22. МихаилМ 25.08.15 19:08 Сейчас в теме
Имел аналогичный опыт. разрушилась база ms sql. комплексная или ут. разрушились Config , params
c dbnames const. это естественно тк они создаются одновременно и находятся в на диске рядом .
таблицы с данными не пострадали. резервных копий нет.


тк я уже ориентировался в структуре таблиц, то подобными "тыканиями" автора не занимался.

я уже знал, что имена таблиц бд с одинаковой конфигурацией могут отличаться.
Поэтому задача стояла так.
1) подобрать по совподению типов полей и их последовательности
нииболее близкую конфу.
2) сделать так что бы имена полей в бд соответствовали и записи dbnames убитой таблицы params
+
скопировать таблицу конфигурации констант,params и ,возможно, dbchema




Было заявлено что конфа полностью типовая.



соответственно нужно было подобрать самую близкую конфигурацию. и по ней восстановить dbnames, const и config . сравнивая структуры таблиц разрушенной и созданными пустыми из конфигураций


я создал несколько пустых баз с разными релизами конфигураций, подходящими по времени создания базы.



создал таблицу описаний таблиц и типов полей

заполнил данными нашел наиболее подходящую. оказалось , что есть недостающие таблицы.
выяснилось , что конфа все таки обновлялась . создал пустые базы с более свежими конфигурациями.

подобрал конфигурацию с полным совпадением по кол-ву таблиц (без const) но не по кол-ву полей . но в анализе я исключил const, тк клиенты сказали что конфигурация не изменялась и они на 80% были разрушены .

Имена таблиц в бд и наиболее подходящей отличались. соответственно нужно было или сгенерировать
правильный dbnames или переименовать поля и таблицы разрушенной бд (в кол-ве 200 шт).

Решил пойти более сложным путем - генерацию dbnames, чтобы иметь опыт полного контроля.

Лишние поля (2 шт ) оказались доработками. Их имена выяснились во внешних обработках. Так же выяснилось, что и константы были добавлены.
удалось выяснить смысл полей константы и подправить конфу.


В итоге

были скопированны из базы образца

таблицы conct , парамс, config, сгененрирована новая запись dbnames в таблице params

в конфигураторе добавлены недостающие поля и константа. их имена исправлены ручками в бд, а не в dbnames
дописана конфигурация изменения проведения по значениям новых полей.

далее ТИИ копии для проверки.

единственное не помню: удалились ли неопознанные поля при реструктуризации.

тк dbnames сжата deflate для чтения-записи использовал http://infostart.ru/public/74406/ спасибо авторам.
sevushka; METAL; +2 Ответить
23. asved.ru 36 26.08.15 12:38 Сейчас в теме
Как говорят на хабре, нет вернее способа угробить карму, чем попросить ее поднять :)
24. METAL 283 31.08.15 12:28 Сейчас в теме
Опубликовано продолжение http://infostart.ru/public/391766/
Пессимистам - просьба не читать :)
Оставьте свое сообщение