Галактика в вопросах и ответах

Добрый день.
Есть рабочая база под 9 ораклом. Ее нужно перенести на другой сервер на котором 10 оракл (для создания тестовой базы). Так как процедура экспорт-импорт требует нескольких рабочих дней, то был выполнен холодный бэкап БД и перенос его на другой сервер.
На этом сервере выполнил:

пересоздание контрольного файла
stratup upgrade
catupgrd.sql
utlrp.sql

полсе чего БД на новом сервере запустилась.
отключил протект abonents.protecton=0

а в галактику войти не могу, получаю

FAILED: OCISessionBegin()
ORA-01017: invalid username/password; logon denied

что еще подкрутить?

А со включенным протектом зайти не получается?.. Помимо установки abonents.protecton=0, Галактика еще выполняет много "хитрых" манипуляций, в том числе и с пользователями...

и с включенным протектом ситация та же.

А пароли?.. Со включенным протектом, попробуйте задать заново пароль пользователю средствами Oracle, любому, чтобы пароли Галактики в таблице x$users совпадали с Oracl'овыми....

А пароли?.. Со включенным протектом, попробуйте задать заново пароль пользователю средствами Oracle, любому, чтобы пароли Галактики в таблице x$users совпадали с Oracl'овыми....

Оп! подскажите как расшифровать пароль в x$users.

Andrey писал(а):Добрый день.
Есть рабочая база под 9 ораклом. Ее нужно перенести на другой сервер на котором 10 оракл (для создания тестовой базы).
....
после чего БД на новом сервере запустилась.
отключил протект abonents.protecton=0

а в галактику войти не могу, получаю

FAILED: OCISessionBegin()
ORA-01017: invalid username/password; logon denied

что еще подкрутить?

логины на новом сервере не пересозданы

на старой базе выгрузите в dbf таблицу юзеров

можете с "отключенным протектом" зайти суппортом в модуль SQL под новым юзером, который автоматом создастся .. /u=newuser
в просмотре словаря (ctrl-f7) открыть на редактирование x$users
и для этого юзера выставить xu$type=1 (сделать админом)

удалить всех юзеров, кроме нового юзера (при необходимости временно выключить триггер на обновление таблицы).

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

Вношу уточнения, так обнаружил кое-какие неточностив своих днйствиях.
При включенном протекте при попытке подключения получаю ошибку

FAILED: OCISessionBegin()
ORA-01017: invalid username/password; logon denied

А при отключенном протекте ошибка следующая:


SELECT XU$FLAG FROM GAL8."X$USERS" WHERE XU$USEROFFICE = 2 AND XU$LOGINNAME$UP = 'GAL2003'
ORA-00942: table or view does not exist

24.07.2009 14:36:43 [GAL2003]:

SELECT DEFAULT_TABLESPACE,TEMPORARY_TABLESPACE FROM DBA_USERS WHERE USERNAME = 'GAL8'
ORA-00942: table or view does not exist

24.07.2009 14:36:43 [GAL2003]:

BEGIN GAL8."EXECUTE"(:P1); END;
ORA-06550: line 1, column 7:
PLS-00201: identifier 'GAL8.EXECUTE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

24.07.2009 14:36:43 [GAL2003]:

CREATE USER "GAL2003" IDENTIFIED BY "GAL2003" DEFAULT TABLESPACE SYSTEM TEMPORARY TABLESPACE SYSTEM
ORA-06550: line 1, column 7:
PLS-00201: identifier 'GAL8.EXECUTE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

24.07.2009 14:36:43 [GAL2003]:

SELECT TABLESPACE_NAME FROM DBA_TS_QUOTAS WHERE USERNAME = 'GAL8'
ORA-00942: table or view does not exist

24.07.2009 14:36:43 [GAL2003]:

Fetch
ORA-24338: statement handle not executed

24.07.2009 14:36:43 [GAL2003]:

BEGIN GAL8."EXECUTE"(:P1); END;
ORA-06550: line 1, column 7:
PLS-00201: identifier 'GAL8.EXECUTE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

24.07.2009 14:36:43 [GAL2003]:

ALTER USER "GAL2003" DEFAULT ROLE ALL
ORA-06550: line 1, column 7:
PLS-00201: identifier 'GAL8.EXECUTE' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

Все рекомендации из темы "Перенос галактики под Oracle на другой сервер" выполнил. Не спасло. Как этот GAL8.EXECUTE должен быть объявлен и где?

проще пройтись кросплатформенным конвертором - медленно, но надежно. А так пока вы chkora не пройдетесь ничего хорошего наверное не будет.

edward_K - это да... если накосячили.. лучше с нуля перекинуть базу через конвертер.. и база причешется...
иначе либо проверить базу чекорой (на выключеном протекте)
или дальше ковырять что еще упустили..

либо делайте как edward_K говорит, самый надежный способ, но если база большая - потребуется время.. либо как я Вам написал можете попробовать.

To Sniper: я же пишу что нет доступа к БД, как же chkora запустить?
Был бы скрипт который из под sqlplus можно было бы запустить?
и второй вопрос: каким запросом из под sqlplus можно увидеть не корректные процедуры и прочее, котрые исправляются chkora.
Запрос типа select * from all_objects where stattus='INVALID' выдает
no rows selected

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

BEGIN GAL8."EXECUTE"(:P1); END;
ORA-30041: Cannot grant quota on the tablespace
ORA-06512: at "GAL8.EXECUTE", line 1
ORA-06512: at line 1

В оракл 10.2 отменена квота на ТЕМП, как победить ошибку не знаю.

Andrey писал(а):...

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

BEGIN GAL8."EXECUTE"(:P1); END;
ORA-30041: Cannot grant quota on the tablespace
ORA-06512: at "GAL8.EXECUTE", line 1
ORA-06512: at line 1

В оракл 10.2 отменена квота на ТЕМП, как победить ошибку не знаю.

Это Вы еще просто не наткнулись на плоды "самодеятельности" поэтому у Вас "все доступно".

Для начала скажу Вам по секрету, что структура БД для Галактики на 9-м оракле имеет отличия от структуры БД ТОЙ ЖЕ самой Галактики, но на 10 и 11-м ораклах.
Минимум в двух местах.

Относительно вопроса как победить квоту на ТЕМП.
Снесите её у владельца Галактической схемы - эту проперть для ораклового юзера Вы втащили вместе с холодной копией базы с экземпляра 9-го оракла.
10-й оракл на это дело "глаза" закрыл - он-то этой пропертью уже не пользуется, а вот попытка чеки восстановить на каждом галактическом пользователе квоты такие же как есть на владельце упирается в стойкое его (оракла 10-го) неприятие подобного деяния - он умножать энтропию несогласен

Кроме того Вам необходимо убедиться, что при "Проверке служебных объектов" чека создала "Расписания"(SCHEDULER) вместо "Заданий"(JOBS), и выдала соответствующие привилегии владельцу схемы
GRANT MANAGE SCHEDULER,CREATE JOB TO ...; (для 10 и выше)
вместо
GRANT EXECUTE ON SYS.DBMS_IJOB TO ...; (для 9)

Вот где-то так...

*P.S. (а протект отключать нужно иначе - так как Вы сделали не получится ...больше так не делайте)

AlexMK писал(а):

Andrey писал(а):...

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

BEGIN GAL8."EXECUTE"(:P1); END;
ORA-30041: Cannot grant quota on the tablespace
ORA-06512: at "GAL8.EXECUTE", line 1
ORA-06512: at line 1

В оракл 10.2 отменена квота на ТЕМП, как победить ошибку не знаю.

Это Вы еще просто не наткнулись на плоды "самодеятельности" поэтому у Вас "все доступно".

Для начала скажу Вам по секрету, что структура БД для Галактики на 9-м оракле имеет отличия от структуры БД ТОЙ ЖЕ самой Галактики, но на 10 и 11-м ораклах.
Минимум в двух местах.

Относительно вопроса как победить квоту на ТЕМП.
Снесите её у владельца Галактической схемы - эту проперть для ораклового юзера Вы втащили вместе с холодной копией базы с экземпляра 9-го оракла.
10-й оракл на это дело "глаза" закрыл - он-то этой пропертью уже не пользуется, а вот попытка чеки восстановить на каждом галактическом пользователе квоты такие же как есть на владельце упирается в стойкое его (оракла 10-го) неприятие подобного деяния - он умножать энтропию несогласен

Кроме того Вам необходимо убедиться, что при "Проверке служебных объектов" чека создала "Расписания"(SCHEDULER) вместо "Заданий"(JOBS), и выдала соответствующие привилегии владельцу схемы
GRANT MANAGE SCHEDULER,CREATE JOB TO ...; (для 10 и выше)
вместо
GRANT EXECUTE ON SYS.DBMS_IJOB TO ...; (для 9)

Вот где-то так...

*P.S. (а протект отключать нужно иначе - так как Вы сделали не получится ...больше так не делайте)

To AlexMK: подробнее про отключение протекта напишите, как правильно сделать. Этот способ отключения протекта на форуме давался неоднократно, срабатывает. "А вредность какая? А мы ее не замечаем."

Andrey писал(а):

To AlexMK: подробнее про отключение протекта напишите, как правильно сделать. Этот способ отключения протекта на форуме давался неоднократно, срабатывает. "А вредность какая? А мы ее не замечаем."

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

надеюсь Вы меня понимаете.

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

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

Вот смотрите ситуация:
1. длина имени объекта в ОРАКЛЕ 30 символов.
2. в зависимости от параметра FullLoginName к имени пользователя, заведенного в Галактике, добавляется (или нет_ префикс равный имени Галактической схемы (базы) + символ #
3. если имеется несколько офисов, то к имени пользователя добавляется символ # и номер офиса.

в результате товарищ "Иванов_Иван_Иванович_01011905" (вполне вроде как легитимный) может превратиться, к примеру, в "GALAXY91#IV ANOV_IVAN_IVANOVIH_01011905#101" и по длине превысит ограничение ОРАКЛА.
Как результат все операции, проводимые, с пользователями "по списку" будут "затыкаться" в этом месте.
Вкл/откл протекта как раз одна из таких операций.
После сбоя половина пользователей до ИванИваныча будет заальтерена к одному состоянию, а другая останется в "протектном", если можно так сказать, виде (или наоборот) ... и возможность работы с Галактикой потеряет.

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

Кто-нибудь всё-таки переходил с 9 на 10 через апгрейд? Получается?

И второй вопрос: Есть, кто работает на Галактике 9 под Ораклом 9? или все мигрировали уже на 10g-11g?