Раздел: проблемы

На небольшом сервере безвозвратно погиб винчестер.От базы остался холодный бекап и архивные файлы журнализации. Это не так уж плохо.

Добавил dbstalker в 16 декабря 2008 г. [Ссылка | Комментарии (2) ]

Согласитесь, бывают радости в нашей жизни. На этот раз - ORA-00600: internal error code, arguments: [12700], [58262], …….

Добавил dbstalker в 25 ноября 2008 г. [Ссылка | Комментарии (2) ]

ОС - WINXP SP2, Oracle 9i. Проблема: база монтируется, но не открывается. В алерте имеем такое сообщение:

Добавил dbstalker в 6 ноября 2008 г. [Ссылка | Комментарии (0) ]

Дела давно прошедших дней, но сегодня вспомнилось. В одном нашем филиале с сервером начались какие-то непонятные вещи происходить: к серверу с утра подключается несколько (5-7) пользователей и работают в поте лица. Затем ни один пользователь не мог подключиться к базе.

Добавил dbstalker в 6 ноября 2008 г. [Ссылка | Комментарии (1) ]

Большинство (или я ошибаюсь?) начинающих администраторов добиваются того, чтобы все (на сколько это вообще возможно) необходимые на протяжении дня данные для работы пользователей находились в буферном кэше, чтобы им приходилось, как можно меньше обращаться к диску за данными. То есть администраторы стремятся к увеличению логического( LIO ) чтения и, соответственно, уменьшению физического ( PIO ) чтения. Показателем этой деятельности есть buffer hit ratio, который стремится к 100%. При высоком значении этого показателя считается, что проблем с чтением данных в базе нет.

Добавил dbstalker в 28 октября 2008 г. [Ссылка | Комментарии (0) ]

Сегодня мне нужно было выгрузить информацию в спул –файл. Данные форматировались с помощью функции rpad. Получили ошибки - «rows will be truncated». В чем же дело?

Добавил dbstalker в 6 октября 2008 г. [Ссылка | Комментарии (2) ]

На одном подшефном сервере работаю нерадивые пользователи: подключаются к серверу с утреца и идут курить на несколько часиков. Научить их жизни не получается. Пришлось побороть их следующим образом:

Добавил dbstalker в 11 июля 2008 г. [Ссылка | Комментарии (6) ]

Самая ПЕРВАЯ обязанность администратора – поддержка базы данных в рабочем состоянии. Даже если в системе происходит сбой (пропало питание, носитель пришел в непригодность и т.д.), администратор должен в максимально сжатые сроки поднять базу без потерь данных. Значит, к сбоям администратор должен готовиться загодя.

Добавил dbstalker в 7 июля 2008 г. [Ссылка | Комментарии (0) ]

На одном из подопечных серверов нужно было удалить пользователя. Но на команду DROP USER my_user cascade было получено сообщение: «ORA-00604: error occurred at recursive SQL level 1 ORA-00942: table or view does not exist».

Добавил dbstalker в 17 июня 2008 г. [Ссылка | Комментарии (4) ]

На сервере oracle 9i версии 9.2.0.6.0 получили в алерте такое сообщение. Нам повезло- отделались малой кровью. Выполнили запрос:

SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME

FROM DBA_EXTENTS 

WHERE FILE_ID = [номер file#] AND [номер block#] BETWEEN BLOCK_ID

AND BLOCK_ID+BLOCKS -1;

Добавил dbstalker в 2 апреля 2008 г. [Ссылка | Комментарии (0) ]

В журнале оповещения alert_my_db.log появились сообщения типа:

Memory Notification: Library Cache Object loaded into SGA
Heap size 2725K exceeds notification threshold (2048K)
Details in trace file /opt/oracle/admin/my_db/bdump/my_db_j003_20259.trc
KGL object name :select /*+ no_parallel(t) no_parallel_index(t) dbms_stats cursor_sharing_exact use_weak_name_resl dynamic_sampling(0) no_monitoring */ count(*),……

Это сообщение memory manager является информационным, угрозы базе данных не несет. Но если вас оно нервирует, то можно поступить таким образом:

Sqlplus  /nolog
SQL> Conn  / as sysdba
SQL> alter system set "_kgl_large_heap_warning_threshold"=8388608 scope=spfile ; 
SQL> shutdown immediate 
SQL> startup

_kgl_large_heap_warning_threshold (maximum heap size before KGL writes warnings to the alert log) – новый недокументированный параметр Oracle 10g

Пожалуй, это все. Если у Вас больше информации, то поделитесь. Будем благодарны.

Добавил dbstalker в 12 февраля 2008 г. [Ссылка | Комментарии (0) ]

Проблемы при инсталляции ORACLE 10g Release 2 (10.2) for Linux x86-64, операционная система Red Hat Enterprise Linux AS release 4 (Nahant Update 4) 2.6.9 42.ELlargesmp (64-bit), платформа x86_64.

Возникло две проблемы:

1. error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory ERROR: ORA-12547: TNS:lost contact
2. startup nomount pfile="/opt/oracle/product/10.2.0/db_1/admin/my_db/scripts/init.ora";ORA-27102: out of memory Linux-x86_64 Error: 28: No space left on device

Добавил dbstalker в 1 февраля 2008 г. [Ссылка | Комментарии (1) ]

Чтобы разобраться в ситуации, когда появляется такое сообщение в журнале оповещений, необходимо предварительно уяснить для себя: что такое нормальная и инкрементальная контрольные точки, а также что такое журналы повторного выполнения.

Добавил dbstalker в 19 декабря 2007 г. [Ссылка | Комментарии (3) ]

Если поврежден неактивный файл, то это вообще не проблема: удаляется и создается заново.

Если поврежден активный или текущий файл?

Добавил dbstalker в 2 ноября 2007 г. [Ссылка | Комментарии (0) ]

После перехода на версию 9.2.0.6, который происходил в авральном порядке и не был продуман, некоторые режимы в эксплуатируемых задачах перестали работать: ORA-03113: end-of-file on communication channel. С этой ошибкой попробуй разберись, что к чему. Порывшись в логах задач, сделали вывод, что используются индексы по функциям и материализованные представления.

Значит, нужно пользователю иметь привилегию query_rewrite и параметры инициализации: query_rewrite_enabled='TRUE', query_rewrite_integrity='TRUSTED'.

Внесли изменения в init.ora и все чудесным образом заработало. Установить эти параметры можно также на уровне сессии командой ALTER SESSION.

Добавил dbstalker в 1 ноября 2007 г. [Ссылка | Комментарии (0) ]

Есть промышленная база данных (primary) и резервная (standby) . Процесс наката журнальных файлов происходил автоматически и без проблем. Случилось так, что standby не работал несколько дней (был выключен). После монтирования резервной базы несколько журнальных файлов не были переданы с primary. В тоже время текущие файлы передаются без проблем. Но накат на standby не происходит, пока не будут получены пропущенные файлы.

Добавил dbstalker в 26 октября 2007 г. [Ссылка | Комментарии (0) ]

Возникла проблема при старте базы: утеряны были не текущие журнальные файлы.С этой проблемой удалось справиться относительно легко.

Добавил dbstalker в 18 октября 2007 г. [Ссылка | Комментарии (0) ]

Нужно было перевести базу данных из режима NOARCHIVELOG в ARCHIVELOG. Возникла на голом месте ошибка ORA-00439:

SQL> conn / as sysdba
Connected.
SQL> alter system set log_archive_dest_1='LOCATION=K:\ORACLE\ORADATA\STK\ARCHIVE';
ORA-00439: feature not enabled: Managed Standby

Оказалось, что для Oracle Standard Edition нужно использовать параметр log_archive_dest.

Добавил dbstalker в 29 ноября 2007 г. [Ссылка | Комментарии (0) ]

На одном из серверов после перезагрузки не происходит автостарт оракла. Хотя в сервисах служба запущена, стартована. В alert.log вообще никаких сообщений нет: будь-то бы оракл и не пробовал стартовать. Если же после перезагрузки вручную запустить оракл, то все нормально.

Добавил dbstalker в 10 сентября 2007 г. [Ссылка | Комментарии (0) ]

Столкнулись с непонятной проблемой: задание (job) автоматически не стартует в указанное время.

Добавил dbstalker в 5 июля 2007 г. [Ссылка | Комментарии (1) ]

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

Добавил dbstalker в 6 июня 2007 г. [Ссылка | Комментарии (0) ]