[ТЕМА ЗАКРЫТА]
08.10.2012 17:31
OlegON
 
В общем, увезли они в другую подсетку сервер - заработало... Выкидывайте керио и винду с сетевых узлов... Сразу.
08.10.2012 17:35
whitewizard
 
наверняка из-за настроек корявых обратные пакетики не возвращались на сервант
26.10.2012 16:22
Stels
 
вопрос по стоимости:
https://olegon.ru/market/buy_opt.php
вверху указано 452,26 ЯД-рублей.
а в форме внизу 450.26

где верно?
26.10.2012 16:36
OlegON
 
Прошу прощения, просчитался. Поправил. Стоимость оптимизатора составляет 450 ЯД лично мне, 2,26 снимает Яндекс.
27.10.2012 11:19
Stels
 
походу сессия опта на сервере висанула
поправь, пожалуйста.
Код:
27.10.12 11:12:00 -- Optimizer for Oracle bases console version 4.10
27.10.12 11:12:00 -- C:\optimizer4
27.10.12 11:12:00 -- Master server: olegon.no-ip.org
27.10.12 11:12:00 -- DB server: *******
27.10.12 11:12:00 -- DB name: XXX
27.10.12 11:12:00 -- Requested commands:o
27.10.12 11:12:00 -- Commands accepted
27.10.12 11:12:01 -- Second connection of optimizer disabled...
27.10.12 11:12:01 -- |
27.10.12 11:12:01 -- ||||||||||||||||||||||||||||||||
27.10.12 11:12:01 -- ||||||||| Start server |||||||||
27.10.12 11:12:01 -- ||||||||||||||||||||||||||||||||
27.10.12 11:12:01 -- DB status : OPEN
27.10.12 11:12:01 -- Client ID : **
27.10.12 11:16:55 -- Client ID : **
27.10.12 11:18:35 -- Client ID : **
27.10.2012 13:49
OlegON
 
Вот как бы по грамотному сделать... На самом деле поводом для такого сообщения - работающий процесс у меня, это уже разбирали. Процесс этот рано или поздно сдохнет - стоит лимит в нем самом и в операционке. Сдыхает не сразу, но сдохнет неминуемо. Сразу сдохнет при корректном завершении сессии. Поэтому писать мне такие сообщения не стоит, если не сутки подконнектиться не дает.
27.10.2012 18:03
Stels
 
Цитата:
OlegON Вот как бы по грамотному сделать... На самом деле поводом для такого сообщения - работающий процесс у меня, это уже разбирали. Процесс этот рано или поздно сдохнет - стоит лимит в нем самом и в операционке. Сдыхает не сразу, но сдохнет неминуемо. Сразу сдохнет при корректном завершении сессии. Поэтому писать мне такие сообщения не стоит, если не сутки подконнектиться не дает.
Спасибо, понятно.
Но похоже из-за ночного сбоя во время MaintenanceTime
пара индексов (SMSPEC..) упала и у оптимайзера завис процесс на сервере.

Я так понимаю, при следующем прогоне он бы сам всё починил.
Но следующего раза по указаным выше причинам не последовало..

Пришлось с утра лечить индексы руками, т.к. в магазине работать не смогли ..
ну и, не удержавшись, написал сюда :)
27.10.2012 18:14
OlegON
 
Есть какие-то идеи на этот счет? Теоретически могу перенести очистку флажков в аккурат перед началом рабочего дня. Но это костыль.
А какой у тебя МТ, что так надолго застряло? У меня сколько клиентов - без проблем... Даже с гадской связью :)
27.10.2012 21:53
Stels
 
00,30;6
если ли бы оптимизатор при обрыве связи заканчивал корректно текущую операцию, то хотя бы можно было работать с базой пусть и без последующего запуска даже в течении суток..

но как это сделать - я е знаю :(
27.10.2012 23:02
OlegON
 
и во сколько оборвалось? сдается, какой-то у тебя косяк, например, десяток обрывов связи. база регеная?
28.10.2012 21:35
Stels
 
хм ... вчера писал ответ ... а он пропал ..

да, база регеная
связь стабильная
вчера упало ~ в 05:07
Код:
27.10.12 05:05:24 -- Gathering list of invalid indexes
27.10.12 05:05:25 -- Rebuilding of SUPERMAG.SMCSPEC_PK :5 : 281Mb
27.10.12 05:06:19 -- Rebuilding of SUPERMAG.SMCSPEC_DISPLAYPOS :4 : 289Mb
27.10.12 05:07:16 -- Rebuilding of SUPERMAG.SMSPEC_CAUSEIDX :3 : 1Mb
27.10.12 05:20:00 -- Optimizer for Oracle bases console version 4.10
сегодня тоже ~ В 05:07
несколько баз
Код:
28.10.12 05:07:19 -- Gathering list of invalid indexes
28.10.12 05:07:20 -- Rebuilding of SUPERMAG.SACSUPPLIERSASSORT_PK :2 : 1Mb
28.10.12 05:07:21 -- Rebuilding of SUPERMAG.SACSUPPLIERSASSORTTREE :1 : 1Mb
28.10.12 05:54:00 -- Optimizer for Oracle bases console version 4.10
28.10.12 05:54:00 -- C:\optimizer4
28.10.12 05:54:00 -- Master server: olegon.no-ip.org
28.10.12 05:54:00 -- DB server: 192.168.5.2
28.10.12 05:54:00 -- DB name: KRAS04
28.10.12 05:54:00 -- Requested commands:o
28.10.12 05:54:00 -- Commands accepted
28.10.12 06:10:00 -- Optimizer for Oracle bases console version 4.10
28.10.12 06:10:00 -- C:\optimizer4
28.10.2012 21:47
OlegON
 
Наверное, я тебя обманул. У меня тут два дня (но, вроде, не подряд) винт вылетал. Винт я убрал, давай посмотрим...
Время очистки флагов я переставил на 06:00 по мск. Т.е. если за ночь залипнет, то к рабочему дню все должно собраться...
01.11.2012 11:32
Vibor
 
Добрый день ВСЕМ.
У меня следующая проблема при запуске оптимайзера он говорит не найден файл optimizer.log
У кого была такая проблема - и как с ней бороться
01.11.2012 12:04
OlegON
 
Можно точное сообщение? Думаю, что это пишет не оптимизатор, а батник, где лог удаляется.
Попробуй запустить команду из батника вручную и посмотреть, что скажет.
01.11.2012 12:28
Vibor
 
JaVA не является внутренней или внешней командой

Добавлено через 13 минут 4 секунды
Олег а как разблокировать базу.?
01.11.2012 12:40
OlegON
 
Цитата:
Vibor JaVA не является внутренней или внешней командой
так верни яву, раз поломал...
Цитата:
Vibor Добавлено через 13 минут 4 секунды
Олег а как разблокировать базу.?
Вот давай только не по оптимизатору тут писать не будем...
01.11.2012 13:34
Vibor
 
Все разобрался, прописал в переменной Path путь до явы
03.11.2012 10:30
OlegON
 
Коллеги, просьба, сбросьте мне на почту лог оптимизатора за сегодняшнюю ночь-утро, у кого IP
Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 21 сообщение(ий)):
У вас нет прав чтобы видеть скрытый текст, содержащийся здесь.

не пойму, оптимизатор выжрал 700Мб, что он делал...
05.11.2012 11:15
student
 
Цитата:
OlegON не пойму, оптимизатор выжрал 700Мб, что он делал...
и по мотивам

https://olegon.ru/showpost.php?p=127402&postcount=316
"Открыл для себя неожиданное умение оптимизатора жрать память не расходуя процессорное время"

очень смахивает на обычную "утечку памяти" - я бы проверился лишний раз на возможные не закрытые объекты - очень похожие симптомы, ограничения по лимиту памяти ничего не дают, спасает только перезапуск...
05.11.2012 11:18
OlegON
 
Эта... Ява... Не дает возможности самому рулить разрушением объектов. Типа ты бросаешь все, как попало, а потом, когда захочется, приходит сборщик мусора и все подчищает, причем, не возвращает память в ОС. Ппц. Вот не первый день мучаюсь, хочу поймать проблему и не удается. В силу, конечно, моего незнания этой самой Явы.
05.11.2012 12:58
student
 
Цитата:
OlegON Эта... Ява... Не дает возможности самому рулить разрушением объектов. Типа ты бросаешь все, как попало, а потом, когда захочется, приходит сборщик мусора и все подчищает, причем, не возвращает память в ОС. Ппц.
просто проверь на явное открытие\создание и явное закрытие\удаление не бросая как попало - сборщик не с первого раза понимает что ему надо сделать и в результате - наложение - утечка
у меня например было что при выходе из процедуры объект в ней созданный не прибивался автоматом\сборщиком
правда у меня не ява, но принципы одни. . . пришлось перешерстить все от начала до конца (убил кучу времени и написал с точки зрения программирования кучу ненужного кода - например явную очистку памяти из-под созданных массивов через арi) но вот уже более 4-х лет утечек не наблюдаю. . .
05.11.2012 13:31
OlegON
 
да в том и дело, что в Java этого всего не сделаешь... по крайней мере на моем текущем уровне ее знания, да и везде пишут, что чистить не нужно...
05.11.2012 16:36
student
 
Насчет явы и очистки в принципе много написано - например









и там не все так однозначно как кажется на первый взгляд :)
попробуй использовать явное присвоение указателю на не нужный более объект - null либо заюзай что либо из профайлеров типа JProbe и OptimizeIt для поимки утечки. . .
05.11.2012 18:50
OlegON
 
ты не представляешь, как я себе тут мозг насиловал, вместо кино вон Шилдта читаю. и уж количество пересмотренного в инете материала исчисляется сотнями ссылок.
явное присвоение null на самом деле мало что дает, а профайлеры невозможно заюзать, поскольку сегодня утром я выпилил последнее, что мне позволяло запускать серверную часть мимо штатного xinetd. Т.е. протестировать кроме как вживую теперь невозможно, но, надо сказать, с начала года я этим и не пользовался ни разу. В общем, жду завтрашнего утра, но пока больше 200Мб экземпляр не выжирает (от 40 до 200 пока из замеченного). Прибил намертво к третьему ядру, лимитировал по времени, перебрал уйму кода, не очень доволен результатом (200Мб все же многовато для консольного приложения с одним соединением к мускулу), но по любому не 700.
07.11.2012 12:20
Kryukov
 
OLEGON-ERROR! : : Low disk space at D:\ORACLE\PRODUCT\10.2.0\ADMIN\DBCENTR\ - 243 Mb
OLEGON-ERROR! : : Low disk space at D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\ - 243 Mb
OLEGON-ERROR! : : Low disk space at D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\ - 243 Mb
OLEGON-ERROR! : : Low disk space at D:\oracle\product\10.2.0\ - 243 Mb
OLEGON-ERROR! : Alert log:


ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.

ORA-27044: unable to write the header block of file

ORA-16038: log 2 sequence# 6052 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-16014: log 2 sequence# 6052 not archived, no available destinations

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.

ORA-27044: unable to write the header block of file

ORA-16038: log 2 sequence# 6052 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-16014: log 2 sequence# 6052 not archived, no available destinations

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.

ORA-27044: unable to write the header block of file

ORA-16038: log 2 sequence# 6052 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-16014: log 2 sequence# 6052 not archived, no available destinations

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.

ORA-27044: unable to write the header block of file

ORA-16038: log 2 sequence# 6052 cannot be archived

ORA-19504: failed to create file ""

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

ORA-16014: log 2 sequence# 6052 not archived, no available destinations

ORA-00312: online log 2 thread 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DBCENTR\REDO02.LOG'

места мало ... что то диск захломило
07.11.2012 13:22
OlegON
 
оптимизатор-то тут при чем? найди, что захламило - оттащи в другое место.
27.11.2012 15:57
omnomnom
 
Как можно понять что оптимайзер отработал полностью?

Можно ли ограничить время mt порядка 3-4 часов в день?

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

Спасибо!
27.11.2012 17:07
OlegON
 
последняя строка заканчивается "************************* the end ***"

можно, особенно если присмотреться к параметрам в соответствующей теме

зарегистрированным наоборот ничего подтверждать не надо, регистрация - уже подтверждение. еще раз предлагаю вчитаться в тему оптимизатора и в то, что уже написано.
13.01.2013 12:56
Mr_Vito
 
обновил версию супермага до 29.3
оптимайзер стал ругаться:
Код:
13.01.13 08:34:53 -- Subpartition defragmentation FF4_2012_PN:0
13.01.13 08:34:54 -- Subpartition defragmentation FF4_2012_PO:0
13.01.13 08:34:55 -- Subpartition defragmentation FF4_2012_PE:0
13.01.13 08:34:56 -- Subpartition defragmentation FF4_2012_IW:0
13.01.13 08:34:57 -- Subpartition defragmentation FF4_2012_CR:0
13.01.13 08:34:58 -- Subpartition defragmentation FF4_2012_CS:0
13.01.13 08:35:05 -- Subpartition defragmentation FF4_2012_WO:0
13.01.13 08:35:07 -- Subpartition defragmentation FF4_2012_WI:0
13.01.13 08:35:09 -- Subpartition defragmentation FF5_2012_PN:0
13.01.13 08:35:10 -- Subpartition defragmentation FF5_2012_PO:0
13.01.13 08:35:11 -- Subpartition defragmentation FF5_2012_PE:0
13.01.13 08:35:13 -- Subpartition defragmentation FF5_2012_IW:0
13.01.13 08:35:13 -- Subpartition defragmentation FF5_2012_CR:0
13.01.13 08:35:14 -- OLEGON-ERROR! : Proc:server:ilishco:java.sql.SQLException: ORA-08103: объект больше не существует
ORA-06512: на  "SYS.DBMS_STATS", line 13437
ORA-06512: на  "SYS.DBMS_STATS", line 13457
ORA-06512: на  line 1

13.01.13 08:35:14 -- Subpartition defragmentation FF5_2012_CS:0
13.01.13 08:35:22 -- Subpartition defragmentation FF5_2012_WO:0
13.01.13 08:35:24 -- Subpartition defragmentation FF5_2012_WI:0
13.01.13 08:35:26 -- Subpartition defragmentation FF6_2012_PN:0
13.01.13 08:35:27 -- Subpartition defragmentation FF6_2012_PO:0
13.01.13 08:35:28 -- Subpartition defragmentation FF6_2012_PE:0
13.01.13 08:35:29 -- Subpartition defragmentation FF6_2012_IW:0
13.01.13 08:35:30 -- Subpartition defragmentation FF6_2012_CR:0
13.01.13 08:35:31 -- Subpartition defragmentation FF6_2012_CS:0
13.01.13 08:35:49 -- Subpartition defragmentation FF6_2012_WO:0
13.01.13 08:35:51 -- Subpartition defragmentation FF6_2012_WI:0
зачем так?
13.01.2013 13:12
OlegON
 
Это не к оптимизатору... Ткни ORA-08103, это стабильно несколько дней? Только на этой табличке?


Опции темы


Часовой пояс GMT +3, время: 10:30.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.