Relic HunterНу и что? На них нету ни патчей ни поддержки. И ограничения не слабые, что по объему, что по железу. 1ГБ ОЗУ и 1 ЦПУ одно слово хе-хе:)
Вы сколько раз обращались в поддержку? :)
Возможно она нужна когда вы купили огромную закрытую систему
и не знаете как она работает внутри.
у нас другой случай - все написали сами, разные грабли оракла обходим с версии 7.
на моей памяти наши DBA обращались в поддержку всего один раз когда действительно
рандомно падала oracle 9.2.0.8 в x64 редакции
вроде специально для нас даже сделали патч и падения прекратились.
По поводу лимитов XE - они для нашей задачи более чем достаточны (у 10 версии по диску 4гб даже на 11 не стали переходить где сделали 12гб)
В локальной базе XE храним документы за последние 3 месяца а все старое подчищается в автомате.
там специфика работы - у них месяц закончился они перекрестились и снова в работу :)
Аналитики сидят в другом месте и смотрят уже в настоящий оракл.
Изя КацманСамое удивительное - ето то, как вам удалось сохранить 240 железяк и как вы их ремонтируете!?
Наверное много точек размещения?
Ремонт идет путем замены старого железа на новое по мере естественной убыли?
Точки раскиданы по всей России - ремонтируют их местные администраторы
есть общий инсталлятор по установке экземпляра база - база ставится даже проще игрушки с DiamondTools :)
+ есть процедура регистрации ID новой базы чтобы документы начали синхронизироваться с центральным сервером.
Азагашсессии не виснут, ожидая dblink? у меня одна из 900 раз в неделю регулярно виснет. прям посреди передачи. и по таймауту отваливаться не хочет. админы руками разводят. не сталкивались с таким?
Конечно виснут но это вообще проблема любых баз Oracle даже EE.
JOB обычно зависает навсегда если в момент передачи рвется TCP
Почему это происходит я не знаю, но лечится пересозданием JOB
я сделал для обслуживающего персонала программу-доктор они запускают его на компе, где стоит XE
он сам в автомате выполняет всей действия по спасению базы и передает нам данные о том как все прошло.
по мере сбора статистики - дополняем "доктора" новыми скриптами.
Убиваем джобы так
1.
2.
3.
4.
5.
6.
for q in (select job
from sys.user_jobs
where what like '%psa.pkg_doc_level3.process_all;%') loop
sys.dbms_job.remove(job => q.job);
commit;
end loop;
и снова создаем через sys.dbms_job.submit
На работу приложения зависшая передача не влияет т.к. она идет асинхронно
и все создаваемые документы всегда сохраняются локально.
единственный минус - если за это время база умрет потеряются те документы, которые не успели передать.
но это как правило бывает редко и мы юзеру подсказываем что джоб встал и
если он не хочет потерять работу нужно или запустить обмен руками или позвать аникейщика для починки автомата.
Также еще вот что делаем - подчищаем зависшие распределенные транзакции.
но тут я сильно не изучал эффекта - вроде помогает
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
begin
dbms_output.put_line('scan sys.dba_2pc_pending');
end;
/
begin
for f in (select local_tran_id from sys.dba_2pc_pending) loop
begin
execute immediate ('rollback FORCE ''' || f.local_tran_id || '''');
commit;
dbms_transaction.purge_lost_db_entry(f.local_tran_id);
commit;
exception
when others then
dbms_output.put_line('rollback FORCE Error = ' || sqlerrm);
end;
end loop;
end;
/
commit
/
begin
dbms_output.put_line('DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(NULL);');
commit;
DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('');
commit;
exception
when others then
dbms_output.put_line('DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY Error = ' || sqlerrm);
end;
/
commit
/
begin
dbms_output.put_line('DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(NULL);');
commit;
for q_purge_mix in (select local_tran_id, mixed from sys.dba_2pc_pending) loop
if q_purge_mix.mixed = 'yes' then
dbms_transaction.purge_mixed(q_purge_mix.local_tran_id);
commit;
end if;
dbms_transaction.purge_lost_db_entry(q_purge_mix.local_tran_id);
commit;
end loop;
exception
when others then
dbms_output.put_line('DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY Error = ' || sqlerrm);
end;
/
commit
/
