Добрый день. Делаем все так как написано в данном руководстве. Сам сервер в домене, доменный аккаунт под которым входим на сервер, входит в группу локальных администраторов.Однако доменная аутенфикация все равно не работает.
"OS_AUTHENT_PREFIX - строковый параметр (значение по умолчанию OPS$) - это префикс прибавляемый сервером Oracle к имени пользователя при сопоставлении имен.
Настоятельно РЕКОМЕНДУЕТСЯ сбросить значение этого параметра (установить его равным пустой строке)."--сделано!
"REMOTE_OS_AUTHENT - булевый параметр (значение по умолчанию FALSE) - разрешение подключаться к серверу удаленным пользователям с доменной авторизацией. Нужно установить его в TRUE."--сделано.
NAMES.DEFAULT_DOMAIN = YOUR_DOMAIN если домен test.local то там надо указать просто test(pre-2000) или test.local?указывали и то и то -результат один.
SQLNET.AUTHENTICATION_SERVICES = (NTS) --сделано
HKEY_LOCAL_MACHINE\ SOFTWARE\ORACLE\HOME№\OSAUTH_PREFIX_DOMAIN--сделано.
Домен на базе Windows 2008 R2. Сервер oracle- на базе Windows 2003 Server.
ошибка-
SQL> connect /
ERROR:
ORA-01017: invalid username/password; logon denied

Что еще можно попробовать?Спасибо!

Уточните пожалуйста, какая версия Oracle используется?

Oracle 10G

Здравствуйте.
Проверьте значения параметров OS_AUTHENT_PREFIX и REMOTE_OS_AUTHENT командой Show parameters %AUTH% (возможно не применились новые значения). Откуда идёт подключение? С самого сервера Oracle? Если "да", то попробуйте установить там дополнительно Oracle-клиент и используйте его "хоум" (установите значение в системной переменной ORACLE_HOME).
С уважением, Terrasoft Support Team.

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

Саша, спасибо за удобный инструмент! С твоего позволения беру в эксплуатацию!
И да +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.

Впринципе, если это часто происходит блокировка пользователей в следствии некорректного воода пароля, то в настройках Oracle параметру FAILED_LOGIN_ATTEMPTS нужно указать UNLIMITED и пользователь блокироваться не будет.

я вообще ничего не понимаю в этом оракле =)
что он хочет?

ALTER USER username ACCOUNT UNLOCK
   2  /
SP2-0640: Not connected