Oracle Support, Oracle на Windows і 3Gb, Інші СУБД, Бази даних, статті

Спочатку опишу проблему:


Після переведення часу у нас встала реплікація, при оновленні снепшот за розкладом витікала пам’ять і падала база, тільки один інстанси, тільки з цього моменту.

Відкрили SR в Oracle Metalink. Благо перший спеціаліст виявився спритним на пошук проблеми і проміжного рішення, встановили job_queue_processes = 0 і при реплікації база падати перестала, але перестало це все справа працювати за розкладом, тільки з ручним запуском. Перенаправили нас з групи по MView групі по джоб. І ось тут з’явилися сферичні коні у вакуумі …

Хто-небудь мені може сказати, чи має сенс встановлювати параметр / 3Gb в вінді (щоб дати можливість адресувати до 3Гб на процес), якщо на ній крутиться інстанси, який при повному навантаженні їсть НЕ більше 500-600 Мб? А ось в металінке вважають, що має. Причому це вони вирішили після тижня розпитувань і роздумів. Сказали наступне:

We suspect that oracle processes reached the 3Gb Limit.

Please cosider setting the /3GB switch then reboot the Windows box and check if the problem is reproducible.

for more information on how to set the /3GB switch please refer to the following


Найцікавіше, що подібне рішення нам пропонували і з іншої проблеми, і теж не допомогло, але там ми спілкувалися через зіпсований телефон під назвою Російський Саппорт Oracle в компанії Академія IT. Там теж були витоку, були треди, які вантажили проц неймовірно, і це були треди від уже закрилися сесій. Так от, рішенням тоді було виставити SQLNET.EXPIRE_TIME = 0. Але це ми дізналися вже після того як самі написали в металінк.

Дик ось виникає питання: / 3Gb – панацея від усіх хвороб? Досвід показує, що ні. Так чому це рішення пропонують по кожній другій проблемі навіть якщо вона ні як не пов’язана з браком пам’яті процесу?


Поки всі пишуть про фішках 11g і проблемах 10g багато хто до цих пір використовують 9iR2. Для тих, хто до сих пір (як і ми) використовує даний реліз СУБД Oracle, Дана запис і написана. А може ще хто з самого Oracle загляне і шепне про рішення проблеми. Отже, почнемо-с.
Прелюдія.
Працюємо ми з Oracle 9.2.0.x досить довго і успішно, по ряду причин керівництво тягне з переїздом на 10-ку, але вже все більше схиляється до нього. Система рознесена географічно на 2 офісу, з цієї причини налаштована реплікація (в обидва кінці). Реплікація створювалася найпростішим способом, створили DBLink, створили Materialized View, що оновлюються за запитом (на всі необхідні таблиці), створили процедуру, що виконує dbms_mview.refresh, і, нарешті, Job, що запускає цю процедуру. Здавалося б простіше нікуди, але це все здавалося до Oracle 9.2.0.5 і першого перекладу часу.
Проблема.
Проблема виникла при перекладі на літній час навесні 2007 року. Полягала вона в тому, що впали обидва інстанси, в обох містах, саме противне, що в 2:00 ночі. Ні, брешу, саме противне, що в логах було пусто, жодного запису щодо падіння, реально нічого, ніби взяв і коректно вимкнувся.
Діагностика.
Ну діагностику я докладно описувати не буду, на деякі речі чисто випадково натрапив, скажу тільки що проблема виявилася як раз в тому, що з якоїсь причини переглючілі Job “и, запускають поновлення уявлень (які, до речі, при job_jueue_processes> 0 оновлюються хитрим способом з використанням пакетних завдань, як і чому не питайте, це приховано в надрах компанії Oracle, Я знаю тільки те, що я знаю). Виглядає це забавно: Job, у якого стоїть статус broken = “Y” або за списком сесій видно, що він не виконується, цокає сумарний час виконання, воно збільшується немов завдання працює.
Рішення.
Рішення, на жаль, не зовсім гарне, але не зовсім зручна і ситуація. Проблема полягає в тому, що після чергового запуску інстанси у нас немає маси часу для роздумів і виконання ряду дій. У кого як, а у нас інстанси валилися протягом максимум 30 секунд після запуску, супроводжувані витоками пам’яті.
1 варіант: відразу після запуску інстанси підключаємося як SYS:
sqlplus “/@mydb as sysdba
читаємо значення проблемного параметри:
SQL> sho parameter job
після цього запам’ятовуємо його (швидко) і встановлюємо його в 0:
SQL> alter system set job_queue_processes=0;
Шукаємо проблемні завдання і перетворюємо їх (так, Вам не здалося, саме створюємо копії, з тими ж обчисленнями поля INTERVAL, з тим самим значенням WHAT), ставимо для старих статус BROKEN = “Y” або взагалі їх прибиваємо.
Повертаємо наш параметр в початкове значення, для варіанту “за замовчуванням” це виглядає так:
SQL> alter system set job_queue_processes=10;
Все! Милицю, але працює і рятує вже 2й раз. Сподіваюся, наступний переклад часу будемо зустрічати на десятці.
2 варіант може знадобитися, якщо інстанси падає занадто швидко. У цьому випадку відразу після запуску інстанси і підключення до нього SQL * Plus робимо наступне:
SQL> shutdown abort;

SQL> startup nomount;

SQL> alter system set job_queue_processes=0;

SQL> alter database mount;

SQL> alter database open;

Далі йдуть описані в першому варіанті дії, починаючи з “Шукаємо проблемні завдання і перетворюємо їх”.

PS: У Oracle Metalink реквест ми звичайно створимо, але минулого разу все закінчилося тим, що я просто перестворити аномальні завдання, а вони закрили SR з позначкою “вирішено клієнтом самостійно”.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*