FoxClub Forums > Не фоксом единым > Oracle. Администрирование. ::

• Войти

Страницы: 1 2 3 4 5 6 7 8 9

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 02.09.16 14:36:25 Igor Korolyov ...Нет, но он сугубо "оптимизационный". При том конкретно такой индекс делает "логически лишним" индекс по ID - правда его нужно было ещё и UNIQUE для полного счастья сделать Хотя с точки зрения оптимизации бывает полезно держать "лишние" индексы - особенно если таблица очень большая и сравнительно статичная - т.е. не претерпевает множества модификаций во время работы системы. Хм... Сделал CREATE UNIQUE INDEX ZAGS_DATA1.IDX_T_ORGANIZATION_01 ON ZAGS_DATA1.T_ORGANIZATION (ID, ID_ROLE_ORGANIZATION) ; План улучшился... Но по моему индекс по ID PK- все равно нужен... На него есть FK с кучи других таблиц... и это уже просто реальность... Igor Korolyov ... Но без постановщика знающего предметную область всё равно не обойтись. С этим я согласен... Я просто сообщу об анализе и все... Спасибо тебе большое...

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

02.09.16 14:36:25

Igor Korolyov
...Нет, но он сугубо "оптимизационный". При том конкретно такой индекс делает "логически лишним" индекс по ID - правда его нужно было ещё и UNIQUE для полного счастья сделать Хотя с точки зрения оптимизации бывает полезно держать "лишние" индексы - особенно если таблица очень большая и сравнительно статичная - т.е. не претерпевает множества модификаций во время работы системы.

Хм... Сделал


CREATE UNIQUE INDEX ZAGS_DATA1.IDX_T_ORGANIZATION_01 ON ZAGS_DATA1.T_ORGANIZATION
(ID, ID_ROLE_ORGANIZATION)
;

План улучшился...
Но по моему индекс по ID PK- все равно нужен... На него есть FK с кучи других таблиц... и это уже просто реальность...

Igor Korolyov
... Но без постановщика знающего предметную область всё равно не обойтись.

С этим я согласен...
Я просто сообщу об анализе и все...
Спасибо тебе большое...

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 02.09.16 17:10:18 В оракле для поддержания первичного ключа (в общем случае это набор полей, не обязательно только одно поле) вовсе не обязательно иметь конкретно индекс по точно такому же набору полей, и даже не обязательно чтобы индекс был уникальным Внешние ключи, соответственно, будут работать с любым вариантом поддерживающим PK (строго говоря, для поддержания констрейна PK индекс вообще не требуется - но тогда любая операция модификации потребует полного сканирования таблицы - потому то оракл и не даёт разработчику сотворить такое безобразие). Кстати, по той же самой причине крайне желательно иметь какой-либо индекс поддерживающий поля FK (не обязательно "просто по этому полю" - индекс может быть и "длиннее") - оракл при удалении записи из "главной" таблицы (или при изменении в ней полей первичного ключа - но это вообще no-no для хорошо спроектированной реляционной БД) должен проверить все ссылающиеся таблицы на предмет того пользует кто там это значение или нет. В твоём случае составной индекс по (ID, ID_ROLE_ORGANIZATION) вполне способен служить в качестве индекса поддерживающего первичный ключ по полю ID. Другое дело, что это может замедлить работу в некоторых случаях, поскольку "маленький" индекс работает быстрее чем "большой" (на операциях полного чтения индекса) - и если где-то для оптимизации было бы достаточно только индекса по ID, замена его на "составной" может ухудшить производительность. Так что просто "добавить" индекс - более безопасно чем "заменить". ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

02.09.16 17:10:18

В оракле для поддержания первичного ключа (в общем случае это набор полей, не обязательно только одно поле) вовсе не обязательно иметь конкретно индекс по точно такому же набору полей, и даже не обязательно чтобы индекс был уникальным

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

В твоём случае составной индекс по (ID, ID_ROLE_ORGANIZATION) вполне способен служить в качестве индекса поддерживающего первичный ключ по полю ID.
Другое дело, что это может замедлить работу в некоторых случаях, поскольку "маленький" индекс работает быстрее чем "большой" (на операциях полного чтения индекса) - и если где-то для оптимизации было бы достаточно только индекса по ID, замена его на "составной" может ухудшить производительность. Так что просто "добавить" индекс - более безопасно чем "заменить".

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 05.09.16 06:56:30 Спасибо...

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 27.09.16 12:31:49 Не знаю, стоит ли заводить отдельный топик... Вопрос больше по Линуксу... У заказчика стоит: Red Hat Enterprise Linux Server release 6.7 (Santiago) И я не могу (по политическим причинам) у заказчика устанавливать ПО... А вопрос, какие аналоги "Шедулеров" лучше использовать в Линуксе ? В текущий момент использую CRON... CRONTAB... Делаю по расписанию создание дампов... Но с ним работать ужас... Редактор его это просто смерть... Может что-то посоветуете ? Типа может у заказчика и стоит новый шедулер, но я об этом не знаю... Или как в CRON-е деактивировать, а потом снова сделать активным выполнение файла в котором идет работа по созданию дампа и записи потом его в архив ? Но т.к. каждые две недели, мы делаем ночью у заказчика обновления, мне нужно деактивировать выполнение файла в указанное время. В текущий момент просто удаляю: $ crontab -r А затем заново формирую строки: $ crontab -e Что не очень удобно... Да, забыл указать, что работаю через putty... Исправлено 1 раз(а). Последнее : ВладимирС, 27.09.16 12:37

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

27.09.16 12:31:49

Не знаю, стоит ли заводить отдельный топик...
Вопрос больше по Линуксу...
У заказчика стоит: Red Hat Enterprise Linux Server release 6.7 (Santiago)
И я не могу (по политическим причинам) у заказчика устанавливать ПО...
А вопрос, какие аналоги "Шедулеров" лучше использовать в Линуксе ?
В текущий момент использую CRON... CRONTAB...
Делаю по расписанию создание дампов...
Но с ним работать ужас... Редактор его это просто смерть...
Может что-то посоветуете ? Типа может у заказчика и стоит новый шедулер, но я об этом не знаю...
Или как в CRON-е деактивировать, а потом снова сделать активным выполнение файла в котором идет работа по созданию дампа и записи потом его в архив ?
Но т.к. каждые две недели, мы делаем ночью у заказчика обновления, мне нужно деактивировать выполнение файла в указанное время.
В текущий момент просто удаляю: $ crontab -r
А затем заново формирую строки: $ crontab -e
Что не очень удобно...
Да, забыл указать, что работаю через putty...

Исправлено 1 раз(а). Последнее : ВладимирС, 27.09.16 12:37

Re: Oracle. Администрирование.
pasha_usue Сообщений: 3649 Откуда: Е-бург Дата регистрации: 06.10.2006	pasha_usue 27.09.16 15:04:12 А скрипты написать, установить CHMOD с правами на запуск, а потом запускать эти скрипты не получается? Скрипты можно к себе в /home положить.

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 27.09.16 15:15:37 Cron неплохой планировщик вообще-то. Скажу больше - мы на нескольких вин-системах порядка 10 лет использовали его порт вместо встроенных виндовых "планировщиков". А твою задачу нужно решать вовсе не сменой планировщика. Нужно переписать сам скрипт создания дампа, добавив в него логический блок - например по наличию файла-флага. И будет достаточно создавать этот файл в начале процесса обновления и убирать в конце - тривиальные touch и rm. ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

27.09.16 15:15:37

Cron неплохой планировщик вообще-то. Скажу больше - мы на нескольких вин-системах порядка 10 лет использовали его порт вместо встроенных виндовых "планировщиков".

А твою задачу нужно решать вовсе не сменой планировщика. Нужно переписать сам скрипт создания дампа, добавив в него логический блок - например по наличию файла-флага. И будет достаточно создавать этот файл в начале процесса обновления и убирать в конце - тривиальные touch и rm.

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 28.09.16 06:59:24 Igor Korolyov Cron неплохой планировщик вообще-то. Скажу больше - мы на нескольких вин-системах порядка 10 лет использовали его порт вместо встроенных виндовых "планировщиков". А твою задачу нужно решать вовсе не сменой планировщика. Нужно переписать сам скрипт создания дампа, добавив в него логический блок - например по наличию файла-флага. И будет достаточно создавать этот файл в начале процесса обновления и убирать в конце - тривиальные touch и rm. Дык я так делаю..., если речь об проверке имеются ли файлы дампов... Но я об другом. Может плохо выразился. И так: Каждый вечер Cron-ом вызываю на выполнение файл создания дампа. В файле предусмотрена логика проверки предыдущего файла дампа и складывание их в архив. Работает как часы. Все хорошо. Но. Т.к. система изменяется, мы раз в 2 недели обновляем ее. При этом мне надо выключить планировщик создания дампа, т.к. в это время производятся работы по обновлению системы, ее тестирование, ... Теперь как выключаю, командой: $ crontab -r Что эта команда делает, она удаляет инфу из crontab для oracle. Т.е. удаляет файл: /var/spool/cron/oracle (если смотреть под пользователем root) Мне после работ, описанных выше, надо восстановить инфу в crontab для oracle. Выполняю команду: $ crontab -e, которая вызывает редактор, в котором заново ввожу строки...(что делать и НЕХОЧЕТСЯ): SHELL=/bin/bash ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 ORACLE_SID=mskdb PATH=/sbin:/bin:/usr/sbin:/usr/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin 30 21 * * * /home/oracle/sv/expdp_mskdb.sh Может лучше просто в редакторе закомментировать строку... # 30 21 * * * /home/oracle/sv/expdp_mskdb.sh а затем ее просто раскомментировать 30 21 * * * /home/oracle/sv/expdp_mskdb.sh Блин... что-то я сразу об этом не подумал... Стоп... А как тогда Cron будет определять, во сколько ему запускаться ? Чего-то не так...(скорее всего будет ошибка при компиляции файла) Может подставлять другой файл (/home/oracle/sv/expdp_mskdb.sh), в котором пусто ... ? Исправлено 4 раз(а). Последнее : ВладимирС, 28.09.16 08:10

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

28.09.16 06:59:24

Igor Korolyov
Cron неплохой планировщик вообще-то. Скажу больше - мы на нескольких вин-системах порядка 10 лет использовали его порт вместо встроенных виндовых "планировщиков".
А твою задачу нужно решать вовсе не сменой планировщика. Нужно переписать сам скрипт создания дампа, добавив в него логический блок - например по наличию файла-флага. И будет достаточно создавать этот файл в начале процесса обновления и убирать в конце - тривиальные touch и rm.

Дык я так делаю..., если речь об проверке имеются ли файлы дампов...
Но я об другом. Может плохо выразился.
И так:
Каждый вечер Cron-ом вызываю на выполнение файл создания дампа. В файле предусмотрена логика проверки предыдущего файла дампа и складывание их в архив. Работает как часы. Все хорошо.
Но.
Т.к. система изменяется, мы раз в 2 недели обновляем ее. При этом мне надо выключить планировщик создания дампа, т.к. в это время производятся работы по обновлению системы, ее тестирование, ...
Теперь как выключаю, командой: $ crontab -r
Что эта команда делает, она удаляет инфу из crontab для oracle. Т.е. удаляет файл: /var/spool/cron/oracle (если смотреть под пользователем root)
Мне после работ, описанных выше, надо восстановить инфу в crontab для oracle. Выполняю команду: $ crontab -e, которая вызывает редактор, в котором заново ввожу строки...(что делать и НЕХОЧЕТСЯ):

SHELL=/bin/bash
ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
ORACLE_SID=mskdb
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin
30 21 * * * /home/oracle/sv/expdp_mskdb.sh

Может лучше просто в редакторе закомментировать строку...


# 30 21 * * * /home/oracle/sv/expdp_mskdb.sh

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


30 21 * * * /home/oracle/sv/expdp_mskdb.sh

Блин... что-то я сразу об этом не подумал...
Стоп... А как тогда Cron будет определять, во сколько ему запускаться ? Чего-то не так...(скорее всего будет ошибка при компиляции файла)
Может подставлять другой файл (/home/oracle/sv/expdp_mskdb.sh), в котором пусто ... ?

Исправлено 4 раз(а). Последнее : ВладимирС, 28.09.16 08:10

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 28.09.16 11:29:45 ВладимирС Дык я так делаю..., если речь об проверке имеются ли файлы дампов... Нет, речь не о файлах дампов. Речь о специальном файле-флаге. Если он есть, то тупо ранний выход из expdp_mskdb.sh и ничего не делаем. Ну можно сгенерить log со строчкой "создание дампа за гггг.мм.дд отменено в связи с проведением регламентных работ". Нет файла - идём дальше выполнять проверки наличия файлов дампа (кстати азанафига? что, они переписывают файлы с одинаковыми именами?) и делать сам дамп... Менять САМИ задания/настройки планировщика не нужно в этом случае. ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

28.09.16 11:29:45

ВладимирС
Дык я так делаю..., если речь об проверке имеются ли файлы дампов...

Нет, речь не о файлах дампов. Речь о специальном файле-флаге. Если он есть, то тупо ранний выход из expdp_mskdb.sh и ничего не делаем. Ну можно сгенерить log со строчкой "создание дампа за гггг.мм.дд отменено в связи с проведением регламентных работ". Нет файла - идём дальше выполнять проверки наличия файлов дампа (кстати азанафига? что, они переписывают файлы с одинаковыми именами?) и делать сам дамп...
Менять САМИ задания/настройки планировщика не нужно в этом случае.

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 28.09.16 13:49:30 Igor Korolyov ВладимирС Дык я так делаю..., если речь об проверке имеются ли файлы дампов... Нет, речь не о файлах дампов. Речь о специальном файле-флаге. Если он есть, то тупо ранний выход из expdp_mskdb.sh и ничего не делаем. Ну можно сгенерить log со строчкой "создание дампа за гггг.мм.дд отменено в связи с проведением регламентных работ"... Т.е. Сделать в expdp_mskdb.sh логику на проверку файла (пусть gen01.sh), если он есть, то дамп не делается, а просто удаляется этот файл. Т.е. на следующий день дампирование пойдет в работу, т.к. файла то нет. А вот при начале работ по обновлению, надо создать его и проводить работы. Я правильно понял ? Igor Korolyov (кстати азанафига? что, они переписывают файлы с одинаковыми именами?) и делать сам дамп... В файле expdp_mskdb.sh прописано, что созданный дамп архивируется zip и переносится на удаленный носитель... Исправлено 1 раз(а). Последнее : ВладимирС, 29.09.16 07:27

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

28.09.16 13:49:30

Igor Korolyov
ВладимирС
Дык я так делаю..., если речь об проверке имеются ли файлы дампов...
Нет, речь не о файлах дампов. Речь о специальном файле-флаге. Если он есть, то тупо ранний выход из expdp_mskdb.sh и ничего не делаем. Ну можно сгенерить log со строчкой "создание дампа за гггг.мм.дд отменено в связи с проведением регламентных работ"...

Т.е. Сделать в expdp_mskdb.sh логику на проверку файла (пусть gen01.sh), если он есть, то дамп не делается, а просто удаляется этот файл. Т.е. на следующий день дампирование пойдет в работу, т.к. файла то нет. А вот при начале работ по обновлению, надо создать его и проводить работы.
Я правильно понял ?

Igor Korolyov
(кстати азанафига? что, они переписывают файлы с одинаковыми именами?) и делать сам дамп...

В файле expdp_mskdb.sh прописано, что созданный дамп архивируется zip и переносится на удаленный носитель...

Исправлено 1 раз(а). Последнее : ВладимирС, 29.09.16 07:27

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 29.09.16 16:35:44 Типа того - но: 1 я бы не называл файл-блокировщик что-то.sh - хотя расширения в лине не имеют такой важной роли как в винде, но это по меньшей мере некрасиво что-то.lock - вполне себе ничего имечко. 2 я бы не прописывал автоудаление такого файла - мало ли, может "процесс" растянется на 2-е суток, или напротив - "обновлятор" уложится до авто-старта... По хорошему флаг должен выставляться в начале и сниматься в конце - если изменения "вручную" вносятся - ну значит и файл "вручную" создавай/удаляй, если это того или иного рода автомат (как это ДОЛЖНО быть по хорошему - шелл-скрипт запускающий тот же sqlplus с путём к sql-скрипту модификации БД, sqlloader и прочие утилиты - возможно даже делающий пред-обновительный дамп для отката "в случае чего"...) ну значит этот автомат и должен создавать и потом удалять файл-флаг... 3 дампы это, конечно, неплохо (а как поток инфы для серверов разработчиков/тестировщиков так и вовсе незаменимая штука) - как "логическая" резервная копия. Но не стоит игнорировать и физические средства архивирования и восстановления - RMAN и всё связанное с ним... ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

29.09.16 16:35:44

Типа того - но:

1 я бы не называл файл-блокировщик что-то.sh - хотя расширения в лине не имеют такой важной роли как в винде, но это по меньшей мере некрасиво

что-то.lock - вполне себе ничего имечко.

2 я бы не прописывал автоудаление такого файла - мало ли, может "процесс" растянется на 2-е суток, или напротив - "обновлятор" уложится до авто-старта... По хорошему флаг должен выставляться в начале и сниматься в конце - если изменения "вручную" вносятся - ну значит и файл "вручную" создавай/удаляй, если это того или иного рода автомат (как это ДОЛЖНО быть по хорошему - шелл-скрипт запускающий тот же sqlplus с путём к sql-скрипту модификации БД, sqlloader и прочие утилиты - возможно даже делающий пред-обновительный дамп для отката "в случае чего"...) ну значит этот автомат и должен создавать и потом удалять файл-флаг...

3 дампы это, конечно, неплохо (а как поток инфы для серверов разработчиков/тестировщиков так и вовсе незаменимая штука) - как "логическая" резервная копия. Но не стоит игнорировать и физические средства архивирования и восстановления - RMAN и всё связанное с ним...

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 18.10.16 07:20:00 Igor Korolyov ... 3 дампы это, конечно, неплохо (а как поток инфы для серверов разработчиков/тестировщиков так и вовсе незаменимая штука) - как "логическая" резервная копия. Но не стоит игнорировать и физические средства архивирования и восстановления - RMAN и всё связанное с ним... Большое спасибо тебе за советы... Но, тут дело оказалось таким... Вроде и дали мне полный доступ у заказчика... Но мое начальство говорит - не суйся... BackUp - это уже дело их админов...

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

18.10.16 07:20:00

Igor Korolyov
...
3 дампы это, конечно, неплохо (а как поток инфы для серверов разработчиков/тестировщиков так и вовсе незаменимая штука) - как "логическая" резервная копия. Но не стоит игнорировать и физические средства архивирования и восстановления - RMAN и всё связанное с ним...

Большое спасибо тебе за советы... :beer2:

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

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 18.10.16 10:11:02 Правильно говорит Нечего добровольно на себя брать ответственность. Вот если официально подрядят следить целиком за БД - вот тогда уж и крути все средства. ------------------ WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 21.10.16 07:56:01 Опять нужна помощь в растолковании... Есть сервер ОС WinServer 2012R2... И когда первый раз (а это было годика 2 назад) попросили поставить Oracle DataBase, я как маленький теленок при установке делал типа <Далее>... и часто не понимая нужно выключать галочки или нет (т.к. за меня они уже стояли) Короче, установил БД "Orcl" как говорится по умолчанию... После, по работе пришлось еще 3 БД на этом сервере установить. Но интенсивно пользователи используют только 2 БД... И вроде все работало... Но уже не в первый раз на меня наезжают, типа БД висит, не можем ничего ввести, и.т.п. и т.д. Вот и вчера наехали... Смотрю в Toad-е "Top Session Finder" и вижу... [attachment 26105 OEM.png] Как я понял это Oracle Enterprise Mamager от пользователя SYSMAN... Т.е. при установке Базы была включена опция "Enterprise Mamager Repository" (а она включена по умолчанию). Теперь сам себе не могу ответить на вопрос, а надо ли это было устанавливать ? Какие плюсы я получил от установки репозитория ? Да, нашел ссылку, что через браузер могу многое смотреть за БД. Обнаружил только сегодня... Но ведь обходился я и без этого... Но получил БОЛЬШОЙ минус в том, что, как я понял, при собирании информации OEM сильно жрет ресурсы. И самое главное он начинает собирать информацию именно днем... Нет чтобы ночью... И вот теперь вопрос, где я могу настроить сбор инфы OEM-ом НОЧЬЮ ? или это неподвласно мне... Или я ЧУШЬ спросил ? И еще один вопрос... смотрю в CMD C:\>set ORACLE_SID=orcl C:\>emctl status dbconsole Oracle Enterprise Manager 11g Database Control Release 11.2.0.3.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. SRV16.MOON.LAN: EM Daemon is not running. ------------------------------------------------------------------ Logs are generated in directory D:\oracle\product\11.2.0\dbhome_1/SRV16.MOON.LAN _orcl/sysman/log C:\>emctl status agent Oracle Enterprise Manager 11g Database Control Release 11.2.0.3.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. --------------------------------------------------------------- Agent is Not Running Но тогда почему в браузере я вижу информацию по БД ? Исправлено 5 раз(а). Последнее : ВладимирС, 21.10.16 09:03

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

21.10.16 07:56:01

Опять нужна помощь в растолковании...
Есть сервер ОС WinServer 2012R2...
И когда первый раз (а это было годика 2 назад) попросили поставить Oracle DataBase, я как маленький теленок при установке делал типа <Далее>... и часто не понимая нужно выключать галочки или нет (т.к. за меня они уже стояли)
Короче, установил БД "Orcl" как говорится по умолчанию...
После, по работе пришлось еще 3 БД на этом сервере установить.
Но интенсивно пользователи используют только 2 БД...
И вроде все работало...
Но уже не в первый раз на меня наезжают, типа БД висит, не можем ничего ввести, и.т.п. и т.д.
Вот и вчера наехали...
Смотрю в Toad-е "Top Session Finder" и вижу...

[attachment 26105 OEM.png]

Как я понял это Oracle Enterprise Mamager от пользователя SYSMAN...
Т.е. при установке Базы была включена опция "Enterprise Mamager Repository" (а она включена по умолчанию).
Теперь сам себе не могу ответить на вопрос, а надо ли это было устанавливать ?
Какие плюсы я получил от установки репозитория ?
Да, нашел ссылку, что через браузер могу многое смотреть за БД. Обнаружил только сегодня... Но ведь обходился я и без этого...
Но получил БОЛЬШОЙ минус в том, что, как я понял, при собирании информации OEM сильно жрет ресурсы.
И самое главное он начинает собирать информацию именно днем... Нет чтобы ночью...
И вот теперь вопрос, где я могу настроить сбор инфы OEM-ом НОЧЬЮ ? или это неподвласно мне...
Или я ЧУШЬ спросил ?

И еще один вопрос...
смотрю в CMD


C:\>set ORACLE_SID=orcl

C:\>emctl status dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.2.0.3.0
Copyright (c) 1996, 2011 Oracle Corporation.  All rights reserved.
SRV16.MOON.LAN:
EM Daemon is not running.
------------------------------------------------------------------
Logs are generated in directory D:\oracle\product\11.2.0\dbhome_1/SRV16.MOON.LAN
_orcl/sysman/log

C:\>emctl status agent
Oracle Enterprise Manager 11g Database Control Release 11.2.0.3.0
Copyright (c) 1996, 2011 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent is Not Running

Но тогда почему в браузере я вижу информацию по БД ?

Исправлено 5 раз(а). Последнее : ВладимирС, 21.10.16 09:03

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 21.10.16 13:02:08 Тоже когда-то поставил EM. Радости не получил, проблем - получил. Не знаю, м.б. для кластеров и ЦОД-ов оно и самое то, а для одиночных БД смысла не вижу (тем паче что для размещённых на одной машине нескольких экземпляров БД в принципе нельзя сконфигурировать ни несколько таких встраиваемых EM, ни заставить EM одного экземпляра обслуживать другие - а ставить "облачный" вариант - тот что Grid/Cloud Control назвается и со своей выделенной БД работает - IMHO перебор для большинства применений этой СУБД и в разработке да и в продакшне). Тем более если речь про софт не обслуживаемый по подписке ораклом (без патчей, саппорта и прочего)... А это похоже твой случай, если не обновился хотя бы до 11.2.0.4 ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

21.10.16 13:02:08

Тоже когда-то поставил EM. Радости не получил, проблем - получил. Не знаю, м.б. для кластеров и ЦОД-ов оно и самое то, а для одиночных БД смысла не вижу (тем паче что для размещённых на одной машине нескольких экземпляров БД в принципе нельзя сконфигурировать ни несколько таких встраиваемых EM, ни заставить EM одного экземпляра обслуживать другие - а ставить "облачный" вариант - тот что Grid/Cloud Control назвается и со своей выделенной БД работает - IMHO перебор для большинства применений этой СУБД и в разработке да и в продакшне).
Тем более если речь про софт не обслуживаемый по подписке ораклом (без патчей, саппорта и прочего)... А это похоже твой случай, если не обновился хотя бы до 11.2.0.4

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 21.10.16 13:15:43 Igor Korolyov Тоже когда-то поставил EM. Радости не получил, проблем - получил. Не знаю, м.б. для кластеров и ЦОД-ов оно и самое то, а для одиночных БД смысла не вижу (тем паче что для размещённых на одной машине нескольких экземпляров БД в принципе нельзя сконфигурировать ни несколько таких встраиваемых EM, ни заставить EM одного экземпляра обслуживать другие - а ставить "облачный" вариант - тот что Grid/Cloud Control назвается и со своей выделенной БД работает - IMHO перебор для большинства применений этой СУБД и в разработке да и в продакшне). Тем более если речь про софт не обслуживаемый по подписке ораклом (без патчей, саппорта и прочего)... А это похоже твой случай, если не обновился хотя бы до 11.2.0.4 Да, у заказчика как раз поставлен "Oracle Enterprise Manager Cloud Control"... и он обслуживает кучу БД... А у нас - как раз случай... "А это похоже твой случай"... Думаю удалить OEM из БД Orcl... Но боюсь потревожить все остальное... Не удалял еще OEM ни разу... А на 11.2.0.4 что-то вовремя не перешли... теперь у заказчика тоже 11.2.0.3 стоит... вот и не переходим...

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

21.10.16 13:15:43

Igor Korolyov
Тоже когда-то поставил EM. Радости не получил, проблем - получил. Не знаю, м.б. для кластеров и ЦОД-ов оно и самое то, а для одиночных БД смысла не вижу (тем паче что для размещённых на одной машине нескольких экземпляров БД в принципе нельзя сконфигурировать ни несколько таких встраиваемых EM, ни заставить EM одного экземпляра обслуживать другие - а ставить "облачный" вариант - тот что Grid/Cloud Control назвается и со своей выделенной БД работает - IMHO перебор для большинства применений этой СУБД и в разработке да и в продакшне).
Тем более если речь про софт не обслуживаемый по подписке ораклом (без патчей, саппорта и прочего)... А это похоже твой случай, если не обновился хотя бы до 11.2.0.4

Да, у заказчика как раз поставлен "Oracle Enterprise Manager Cloud Control"... и он обслуживает кучу БД...
А у нас - как раз случай... "А это похоже твой случай"...
Думаю удалить OEM из БД Orcl...
Но боюсь потревожить все остальное...
Не удалял еще OEM ни разу...

А на 11.2.0.4 что-то вовремя не перешли... теперь у заказчика тоже 11.2.0.3 стоит... вот и не переходим...

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 21.10.16 14:05:06 Я тоже не стал удалять, экземпляр старинный, потиху схемы уходят на другие экземпляры и даже сервера (на 12-ку, или кто-то на XE, а перспективы есть и на постгрес кое что пересадить - всё в виртуалках, естественно). Думаю проще пересоздать этот экземпляр, точнее создать новый и перенести туда схемы. Сами агенты/сервисы ты походу уже отключил, или они сами "сломались" ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

21.10.16 14:05:06

Я тоже не стал удалять, экземпляр старинный, потиху схемы уходят на другие экземпляры и даже сервера (на 12-ку, или кто-то на XE, а перспективы есть и на постгрес кое что пересадить - всё в виртуалках, естественно). Думаю проще пересоздать этот экземпляр, точнее создать новый и перенести туда схемы. Сами агенты/сервисы ты походу уже отключил, или они сами "сломались"

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 21.10.16 14:51:46 Igor Korolyov ... Сами агенты/сервисы ты походу уже отключил, или они сами "сломались" Да я об агентах только сегодня утром прочитал и начал смотреть...

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 26.10.16 10:49:13 Хм... Прислали с курсов инфу... Новые возможности для администраторов баз данных Цитата: Код: Or12c_NFA Длительность: 40 ак.ч. Стоимость: 49 950 р. Спросил у начальства... Сказали оплатят 50%, остальное сам... Да и проезд наверное сам... Вот и задумался, а стоит ли ?

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

26.10.16 10:49:13

Хм... Прислали с курсов инфу...
Новые возможности для администраторов баз данных

Цитата:
Код: Or12c_NFA
Длительность: 40 ак.ч.
Стоимость: 49 950 р.

Спросил у начальства...
Сказали оплатят 50%, остальное сам... Да и проезд наверное сам...
Вот и задумался, а стоит ли ?

Re: Oracle. Администрирование.
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002	Igor Korolyov 26.10.16 11:20:48 Если не собираешься в ближайшее время менять работу, и на текущей не обещают подкинуть плюшек за "дипломированного специалиста", то я бы не стал - тем паче за свои кровные, пусть и наполовину ------------------ WBR, Igor

Re: Oracle. Администрирование.

Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002

Igor Korolyov

26.10.16 11:20:48

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

------------------
WBR, Igor

Re: Oracle. Администрирование.
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005	ВладимирС 26.10.16 11:33:42 Igor Korolyov Если не собираешься в ближайшее время менять работу, и на текущей не обещают подкинуть плюшек за "дипломированного специалиста", то я бы не стал - тем паче за свои кровные, пусть и наполовину У нас только индексация з/пл в конце года...

Re: Oracle. Администрирование.

ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005

ВладимирС

26.10.16 11:33:42

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

У нас только индексация з/пл в конце года...

Страницы: 1 2 3 4 5 6 7 8 9

:: Список Форумов•Список тем•Поиск•Войти

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

On-line: 4 (Гостей: 4)