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

При откатывании тоже возникла ошибка и система сообщила, что восстановление из бэкапа невозможно.

При этом в интерфейсе системы и в БД пропали некоторые поля и такое ощущение, что система откатилась примерно на месяц назад.

Подскажите, пожалуйста, как можно диагностировать до какого бэкапа откатилась система? Где хранятся созданные при установке пакетов бэкапы?

Нравится

1 комментарий

При установке пакета делается слепок некоторых таблиц на текущий момент, а при откате он разворачивается. Более старых, если накатывали и сразу отменяли, быть не должно. Возможно, исчезновение полей связано как раз с тем, что они совпали с накатываемыми из пакета и при удалении пакета их тоже убрало.

Перед установкой будет лучше всего делать полный бекап средствами базы, чтобы потом при необходимости его развернуть.

Показать все комментарии

Коллеги, здравствуйте! 

Хотелось бы уточнить какие методы есть для отката системы в случае диверсии со стороны администратора CRM?

Пример: удаление данных произошло в 11 вечера, на сл.день велась работа в системе. Каким образом можно откатить данные на 11 вечера и подтянуть данные со следущего утра?



Спасибо!

Нравится

1 комментарий

Здравствуйте!

Методов для отката системы на уровне приложения нет. Как вариант, вы можете настроить журнал изменений, по интересующим вас объектам, он зафиксирует какие изменения были сделаны и от какого пользователя:

https://academy.terrasoft.ru/documents/sales-enterprise/7-11/razdel-zhu…

Рекомендую настроить резервное копирование БД по расписанию, это позволит минимизировать возможные проблемы с потерей данных.

 

Показать все комментарии

Здравствуйте!
Для того что бы клиенты не волновались о информации которую они передают нам вместе с бэкапом базы данных Terrasoft, порой необходимо обезличить данные.
Это можно сделать, превратив данные в вид
"Контрагент {ID контрагента}"
и сохранить при этом связи.

В прикрепленных файлах, обезличивание основных разделов системы для XRM + Service Desk 3.4.0.54 простыми update'тами.

Нравится

Поделиться

0 комментариев
Показать все комментарии

Добрый день!
Подскажите пожалуйста, как можно менее проблематично перенести базу данных на Firebird с версий 3.2.0 на 3.3.2 (Terrasoft)
Заранее спасибо!

Нравится

10 комментариев

Базовая версия или проектное решение?

проектное решение ... Утилиты переноса сервисов и перехода версий support предоставил ... А как быть с самой базой и данными в ней ?

Под SQL есть альтернатива - переносим доработки руками в виде сервисов или вновь внося изменения, а затем данные перебрасываем с помощью Red Gate. Но вот аналога этой утилиты для firebird я не знаю...

Почитайте эту ветку: http://community.terrasoft.ua/blogs/5200
Возможно это Вам поможет.

База Firebird ... требуется перенести данные из старой базы в новую (обновление Terrasofta до 3.3.2)
Спасибо заранее за советы

Здравствуйте!

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

Инструкция по обновлению прикреплена.

А почему не переносятся окна и некоторые скрипты ?
А при переносе вручную (выгрузка/загрузка сервисов) окно переносится, а поля нет ?

В пакетах обновления приоритет выставлял на замену из пакета (при конфликтах)

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

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

Советую Вам попытаться провести обновление и при этом проводить слияние сервисов вручную.

"Симоненко Влад" написал:Советую Вам попытаться провести обновление и при этом проводить слияние сервисов вручную.

Что и делаю, но при загрузке сервиса окна, (выгрузка из предыдущей версии и загрузке в новую) в новой не не отображаются поля окна :(

Скорее всего при переходе что-то было неправильно сделано.
Попробуйте сделать все с начала и если ошибка останется - посмотрите в TSAdmin почему не отображаются эти поля (не перенесен сервис, названия полей пустые, неправильное окно и т.д.), тогда станет ясно почему возникает данная ошибка.

Показать все комментарии

Добрый день, участники сообщества!
По многочисленным просьбам сегодня я расскажу как можно создать и поднять бэкап Terrasoft на СУБД Oracle.
Сделать это очень просто, все делается автоматически -- нужно лишь  запустить командный файл и ввести названия базы данных.

Создание бэкапа

  1. Распаковываем содержимое архива Backup.zip на сервер, где установлен сервер Oracle.
  2. Запускаем BackupDatabase.cmd.
  3. Указываем: название схемы, ее пароль (схемы-пользователя) и название файла дампа базы.
  4. В результате получаем два файла: Grant.sql -- скрипт по созданию розданных прав и собственно сам дамп базы Oracle.

Поднятие бэкапа

  1. Распаковываем содержимое архива Restore.zip на сервер, где установлен сервер Oracle.
  2. Сюда же обязательно подкладываем два файла (Grant.sql и дамп), которые были созданы при создании бэкапа.
  3. Запускаем RestoreDatabase.cmd.
  4. Указываем: пароль пользователя SYS, название файла дампа базы (backup db file name), старое название схемы с которой делался дамп (old user schema), название новой схемы (new user schema) и пароль пользователя новой схемы (new user password).
  5. Дальше все выполнится автоматически: создастся новая схема, раздадутся нужные права, создадутся нужные типы,  подымется бэкап базы под указанной схемой, заменятся завязки объектов в системных таблицах Terrasoft на новые, раздадутся нужные права ролям на таблицы и представления.
     

В инсталляции Terrasoft уже идут в комплекте похожие скрипты, но там все завязано на то, что база создавалась со схемы TSAUTOBUILD. Мои скрипты дополнительно запрашивают название старой схемы.

  Описал коротко, только самое нужное. Если будут вопросы - с удовольствием отвечу.

Отмечу, что выложенную информацию необходимо рассматривать как пример, который каждый можете менять под свои потребности. Эти скрипты применимы для Oracle установленного на ОС Windows и запуск командного файла нужно производить на самом сервере. Для всех остальных вариантов (другая ОС, запуск с клиентской машины) можете дописать сами.

Ключевым моментом при создании бекапа является скрипт Grant.sql (см. Backup.zip), который создает "слепок" розданных прав для модели, которая применена в Terrasoft CRM.

UPD: Спасибо Саше Котенко за найденный недочет в файле BackupDatabase.cmd. Исправил.

Нравится

Поделиться

13 комментариев

Большое спасибо, Саша.

Саша, спасибо за удобный инструмент! С твоего позволения беру в эксплуатацию!
И да +1 :wink:

Саша, огромное спасибо! Данная инструкция и материал очень помогут всем, кто сталкивается с Oracle-версией продукта.

Указывайте пожалуйста требования к использованию скриптов.
Здесь:
1. скрипт для Windows (чаще для поддержки Oracle используются другие ОС),
2. вне скрипта определена переменная среды ORACLE_SID.
Согласно документации рекомендованно:
1. формат авторизации sqlplus из командной строки (например BackupDatabase.cmd строка 12) определяется как sqlplus login/password@sid, а в Вашем случае (без указания сида) получим ERROR: ORA-12560: TNS:ошибка адаптера протокола
2. Использование команды без логирования тоже не лучший вариант.

ihmo статья скорее вредна, очень удивили оставленные комментарии :(

to alexk
Ничего удивительного в этом нет. Для кого-то информация полезна, например для тех, кто не часто сталкивается с Oracle. А для того, кто имеет больше опыта работы с Oracle, что-то может показаться очевидным. В любом случае, спасибо за комментарии. Внесем необходимые корректировки.

Здравствуйте.У меня возник вопрос.Мне предстоит установить сервер Terrasoft и интегрировать террасофт в существующую структуру.но никогда не работал с базой даннх оракл.
Как я понимаю пункт 1 надо делать, если существует старая база данных?Или как? В руководстве описано по другому.Но в руководстве как я понял предполагается что сервер базы данных оракл и сервер террасофт это один физический компьютер.А мне надо разнести их по разным ролям.в руководстве написано:
Для восстановления БД на сервере необходимо:
1. Запустить файл RestoreDatabase.cmd, который находится в
директории \DB>, нажав
на клавишу [Enter].
Какой сервер иммется ввиду?Наверно сервер баз данных оракл?Но там этого пути не будет если сам софт будет стоять отдельно!Помогите разобраться пожалуйста!

Здравствуйте.

Такого понятия как "сервер Террасофт" - не существует. Вы устанавливаете БД Oracle на машине, которую назначите в роли сервера БД. Далее Вы устанвливаете клиентские приложения Террасофт и соединение с БД соглагласно руководству.

Terrasoft Support Team.

Есть ли изменения в инструкции(по созданию/поднятию бекапа) для версий 3.4.0+ ?

Немного подкорректировал скрипт SysGrants.sql из инструментария восстановления бекапа версии 3.3.2.

Ранее там было указано:

GRANT SELECT ON TSAUTOBUILD.TS_CONS_COLUMNS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_CONSTRAINTS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_IND_COLUMNS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_INDEXES TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_TAB_COLS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_TAB_COLUMNS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_TABLES TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_TRIGGERS TO PUBLIC;
GRANT SELECT ON TSAUTOBUILD.TS_VIEWS TO PUBLIC;

В результате чего приходилось вручную заменять TSAUTOBUILD на имя вашей схемы, откуда происходил экспорт. Теперь это название будет автоматически подтягивать имя из введенной вами информации при запуске RestoreDatabase.cmd.

Исправленный restore_3_3_2.zip обновлен.

Клиенты часто спрашивают, почему при поднятии резервной копии Oracle выдает предупреждения, а также почему некоторые объекты после импорта в невалидном состоянии.

Попытаюсь ответить на эти вопросы.

Тип объекта "SCHEMA_NAME"."t_FieldInfo" уже существует с другим идентификатором

В нашей системе используются объектные типы БД Oracle, OBJECT TYPE.

Дело в том, что Oracle жестко связывает объектные типы с их идентификаторами, OID.

При этом если на сервере был однажды восстановлен бекап схемы Terrasoft, там создадутся все используемые типы ("t_GetLoginInfo", "tbl_GetLoginInfo" и др.).
Но из-за жесткой привязки к OID, эти типы создадутся с OID, который прописан в дампе.

Первый раз все будет нормально. Но при поднятии того же, либо другого бекапа схемы Terrasoft на том же сервере, он опять будет создавать типы с теми же OID – в результате возникнет ошибка: объект с таким OID уже существует. В результате после поднятия бекапа ни один из типов не создастся.

Из-за этой особенности Oracle, мы сделали в скриптах поднятия наших схем обходное решение:

  1. Перед поднятием бекапа скриптом CreateTypes.sql явно создаются все необходимые типы, при создании Oracle сгенерирует им новые OID.
  2. При поднятии Oracle пытается создать типы из бекапа c их старыми OID, при этом выдается ошибка IMP-00061: Внимание: Тип объекта "Схема"."Тип" уже существует с другим идентификатором

При возникновении такой ошибки, создание типа пропускается.

Но в нашем случае это не является ошибкой, т.к. это сделано специально в качестве обходного решения. Все необходимые объектные типы создадутся нашим скриптом непосредственно перед поднятием бекапа.

Подробнее об этом в документации Oracle.

После поднятия бекапа некоторые объекты невалидны

Это также не является ошибкой, а просто предупреждением.

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

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

Переходим от теории к практике. В нашей системе у многих таблиц есть строчный триггер BEFORE INSERT OR UPDATE, например такой:

CREATE OR REPLACE TRIGGER "tr_tbl_Activity_BI"
BEFORE INSERT ON "tbl_Activity" REFERENCING NEW AS New OLD AS Old
FOR EACH ROW
BEGIN
  IF (:NEW."ID" IS NULL) THEN
    :NEW."ID" := "fn_CreateGUID"();
  END IF;
END "tr_tbl_Activity_BI";
/

Как видим по коду, этот триггер вызывает функцию fn_CreateGUID, которой на момент переноса триггера просто нет. Она создастся позже, со всеми остальными ХП. Из-за этого триггер остается невалидным.

Но это абсолютно нормальная ситуация. Дело в том, что любой объект БД Oracle, находящийся в невалидном состоянии будет автоматически скомпилирован СУБД "на лету", при первом обращении кнему. В этот момент уже будут доступны и валидны все зависимые объекты (ХП, Типы и т.д.) и триггер скомпилируется корректно и станет валидным.
Подробнее об этом в документации Oracle.

Система администрирования Oracle в версии 341 существенно изменилась. В связи с этим, изменился также и механизм создания и восстановления резервных копий.

Что изменилось в новых скриптах работы с бекапами для 341

  • Появилась возможность указывать инстанс Oracle для разворачивания бекапа
  • Можно указать отдельное табличное пространство для разворачивания схемы
  • Исправлена ситуация с экспортом пустых таблиц (Oracle 11)

В новой системе администрирования практически все права пользователю назначаются через роли. Поэтому при восстановлении резервной копии появилось 3 опции - режимы переноса прав пользователей. Остановлюсь на этом более подробно.

Опция № 0 - Перепривязать пользователей в новую схему (по умолчанию)

При этом все пользователи Terrasoft, создадутся и им будут розданы и назначены по-умолчанию роли для доступа к новой схеме (к той которую вы разворачиваете). У пользователей автоматически заберется доступ на старую схему. Этот вариант подходит для первоначального поднятия бекапа на новом инстансе либо для перенос боевой схемы в новую схему.

Опция № 1 - Создать пользователей с перименованием

Этот вариант предполагает, что все пользователи Terrasoft будут созданы как новые пользователи Oracle c префиксами 'U' и им будет розданы все соответствующие права. Например в старой схеме был пользователь User1, после поднятия резервной копии новый пользователь будет User1U. Таким образом старый пользователь User1 будет продолжать нормально работать со старой схемой, а новый будет иметь все те же права в отношении новой схемы на одном инстансе. Этот вариант удобен при поднятии тестовой схемы на том же инстансе, где уже работает боевая схема. При этом пользователи будут абсолютно независимы.

Опция № 2 - Не создавать пользователей

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

И самое главное, скрипты в прикрепленном архиве.

А кто-то по этой инструкции восстанавливался из бекапа? Расскажу свою историю: все восстановилось и заработало, все права пользователи получили. Но при создании нового пользователя возникли проблемы http://www.community.terrasoft.ua/forum/topic/8609, а при создании новой таблицы возникли такие проблемы http://www.community.terrasoft.ua/forum/topic/8611.

Это только у меня такие проблемы или всё-таки скрипт не совсем корректно восстанавливает права на объекты? Может кто-то проверить на вновь созданой БД, а не в другой схеме?

Здравствуйте.
Этот вопрос обсуждался в рамках Вашего обращения №0122356 в службу технической поддержки.
С уважением Terrasoft Support Team.

Показать все комментарии