dbstalker Profile

Стив Адамс имеет наглость по этому поводу утверждать следующее:

512 bytes	  Solaris, AIX, Windows NT/2000, Linux, Irix, DG/UX, OpenVMS, NetWare, UnixWare, DYNIX/ptx  
1024 bytes	  HP-UX, Tru64 Unix
2048 bytes	  SCO Unix, Reliant Unix
4096 bytes	  MVS, MPE/ix

Вы правы.Это уже клинический случай. исправляем. Спасибо!!!

min

у меня работает и на 9 и на 10

Спасибо за ценную информацию. Кстати, в интернете можна найти OraMsgViewer - хорошая программулька по ошибкам оракла с учетом версий.

Благодарю! Надеюсь на такое же внимание к моему блогу и в дальнейшем.

используйте утилиту Data Pump Export

А если попробовать так: select CITY, NAME, PERIOD,goods from (SELECT CITY, NAME, PERIOD,goods, row_number() OVER(partition by city,name,period ORDER BY goods desc) toprank FROM DBST_TABL) where toprank<=[указанное Вами число N]?

Да, Вы правы. Там,действительно, без иерархий. Но, если Вы обратили внимание, там ограниченное число строк превращается в ограниченное число столбцов. Если Вы уже подняли вопрос транспонирования таблицы, то могу вам посоветовать еще один мой пост Как транспонировать таблицу в ORACLE. Благодарю за внимание к моему блогу!

Было бы всем интересно, если бы Вы показали, как рассматриваемая в посте задача решается с использование Data Cartridge на конкретном примере.

если добавить commit после команды: update demo set theblob=empty_blob() where id=1; , то результат не изменится. в переменных the_blob1 и the_blob2 остается тоже значение, что и было. В записи с id=1 сначала будет пустой локатор, а потом эта запись удаляется.

Тело блоба физически находится в своем табличном пространстве. обратите большее внимание на специфический механизм многовариантности для таких типов объектов.

Как толко вы выполнили такой update, то оракл считает, что нет ни локатора ни значения у объекта.Только не думайте, что табличное пространство сразу же уменьшится на размер BLOBа.

цитата из поста:"Прежде чем выполнять запись во внутренний большой объект, необходимо заблокировать строку, которая содержит столбец этого объекта. Это можно сделать явными блокировками или sql –операторами: select for update, update, insert." СМ. выше.

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

Запрос на выборку НЕ провоцирует генерацию SCN , а вызывает ЗАПОМИНАНИЕ SCN, который сгенерирован какой-то транзакцией.

Ваше внимание очень приятно. На Ваш вопрос отвечу так как я понимаю (на самом деле все несколько иначе, но так проще для понимания. Хотя суть такая же): начинается транзакция. Оракл фиксирует текущий SCN (в любой момент времени можно выполнить запрос select dbms_flashback.get_system_change_number from dual и Вы тоже сможете узнать на данное время какой текущий SCN в базе). Этот номер дальше назовем начальным для нашей транзакции. Этот номер для каждой активной транзакции можно увидеть в поле START_SCNB представления v$TRANSACTION. Дальше данные обрабатываются после предварительной сверки начального SCN c SCN выбраных данных исходя из многоверсионности данных в оракле.Во время фиксации транзакции генерируется SCN данной транзакции. Текущий SCN также можно узнать по запросу select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe. Но вы должны знать, что в базе существуют тьма разных SCN: current SCN, commit SCN, transaction start SCN, checkpoint SCN...

По поводу commit SCN и transaction start SCN- нужно почитать про транзакции, о checkpoint SCN - про контрольные точки. Об этом есть немного материала на моем блоге. О current SCN - Вы уже знаете из моего предыдущего ответа. Больше информации по SCN будет в материале об undo, который я все ещё планируюю выложить на свой блог.

Ответ на первый Ваш вопрос: PCTFREE - процент пространства блока для выполнения команд update для данных, которые уже находятся в этом блоке. Если блок находится в списке свободных блоков, то в блок вставляются строки (insert новых данных) до тех пор, пока в блоке данные не будет занимать место в процентном отношении равное 100%- PCTFREE (если пренебречь служебным пространством). Например, если PCTFREE=10%, пренебрегаем служебным пространством, то вставлять данные в блок будем до тех пор, пока они не займут 90% блока. После того как данные будут занимать все 90%, блок будет выкинут из списка свободных блоков, т.е. новые данные вставляться в него не будут. Но если будет необходимость обновить данные, которые уже есть в этом блоке, то оставшиеся 10% могут быть использованы для этого (размер данных после обновления может быть больше, чем до него) PCTUSED - минимальный процент пространства блока, не менее которого мы хотим, чтобы был занят каждый блок. Если блок в свое время был выкинут из списка свободных блоков (занятое пространство – 90%), а затем из него удалили данные, и процент занятого пространства стал ниже заданного pctused (по умолчанию 40%) , то блок снова вносится в список свободных блоков. Таким образом, в него снова можно вставлять новые данные. Проще говоря: Если занятого пространства так много, что оно составляет 90% - вставлять новые данные нельзя. Если занятого простанства стало так мало, что меньше 40% - в него снова можно вставлять данные. Таким образом, противоречия я не вижу.

Ответы на остальные два вопроса сейчас маленькими постами оформляю. Вопросы задавайте любые - буду стараться отвечать. А если хотите поделиться своим опытом, то пока на it-blogs.com нет возможности каждому заводить блоги. Но я с радостью размещу ваши материалы с указанием вашего авторства.

Первое, что пришло в голову: повесить на "буфер" триггер на событие "delete" (т.е. когда записи переносятся в "лог"), который будет добавлять записи из "источника". Может быть, на время вставки нужно будет заблокировать "буфер". Вот такое предложение, если условия задачи мною поняты правильно.

Первое,если у Вас вопросы не по теме поста, то будет лучше, если Вы будете писать мне на E-mail. Второе, по-прежнему видно не понимаю сути проблемы. Поэтому совет чисто интуитивный: ройте в сторону пакетов dbms_alert и dbms_pipe.

Это ответ на третий Ваш вопрос о мигрирующих строках: http://my-oracle.it-blogs.com/post-237.aspx

Полным ответом на Ваш второй вопрос может служить статья Скулкина Дмитрия "Управление пространством внутри блока данных". А так же мой очень-очень упрощенный пост "Очистка блоков данных" "Очистка блоков данных"

Бесспорно! Напишите статью и пришлите нам - мы разместим её в разделе 'Посты наших читателей'

в ответе на ваш вопрос ключевым будет "список свободных блоков". Упрощенно:совершенно пустой блок попадает в этот список и заполняется до тех пор, пока не будет заполнен на 100%-PCTFREE, то есть на 90% в нашем случае. после чего он из списка удаляется. то есть новые записи в него не будут попадать до тех пор пока он снова не попадет в список свободных блоков. а попадет он в этот список только тогда, когда заполненого места в нем станет мало, меньше , чем PCTUSED. вывод: будут ли вставлятся записи в блок зависит от PCTFREE,PCTUSED, заполненности и нахождения в списке свободных блоков.

Да - если он в списке свободных блоков. Нет - если он отсутствует в списке свободных блоков.

Это тема для статейки. Ждите - напишу.

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

Мое мнение вряд ли Вам понравится: нужно с ораклом работать. Работать каждый день. И только тогда чтение литературы даст положительный эффект. Чтение без практики - пустая трата времени.Успехов! Просьба: аналогичные вопросы лучше задавать в разделе "Читателям -Задать вопрос и получить ответ - уже решено 8 вопросов".

Для девятки, например, файл паролей - C:\oracle\ora92\database\pwdmy_db.ora, файл инициализации - C:\oracle\ora92\database\initmy_db.ora или C:\oracle\ora92\database\spfilemy_db.ora

Вы правы, материал изложено несколько избыточно ( база переносится на другой сервер и переименовывается). Постановка задачи указана в начале статьи. Если же вам не нужно переносить базу данных на другой сервер, то совсем просто самостоятельно адаптировать изложенную технологию для Вашего случая. Просто чаще всего ( в моём случае также) приходится переносить базу на другой сервер и переименовывать. Успехов Вам!

Трудно сказать почему у Вас не восстановилась передача редо логов. Только что было проверено этот механизм :

SQL> recover managed standby database disconnect from session;
Media recovery complete.
SQL> RECOVER MANAGED STANDBY DATABASE  FINISH;
Media recovery complete.
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Media recovery complete.

Media Recovery Waiting for thread 1 seq# 14660
Tue Jun 24 17:02:00 2008
ALTER DATABASE RECOVER  MANAGED STANDBY DATABASE  FINISH  
Tue Jun 24 17:02:00 2008
Terminal Recovery: request posted
Tue Jun 24 17:02:12 2008
There are no standby current logs; terminal recovery is not required.
MRP0: Background Media Recovery user canceled with status 16137
Recovery interrupted.
Tue Jun 24 17:02:12 2008
Waiting for MRP0 pid 2160 to terminate
Tue Jun 24 17:02:13 2008
MRP0: Background Media Recovery process shutdown
Tue Jun 24 17:02:13 2008
Terminal Recovery: completion detected
Completed: ALTER DATABASE RECOVER  MANAGED STANDBY DATABASE  
Tue Jun 24 17:02:39 2008
ALTER DATABASE RECOVER  MANAGED STANDBY DATABASE DISCONNECT FROM SESSION  
Attempt to start background Managed Standby Recovery process
MRP0 started with pid=14
MRP0: Background Managed Standby Recovery process started
Media Recovery Waiting for thread 1 seq# 14660
Tue Jun 24 17:02:45 2008
Completed: ALTER DATABASE RECOVER  MANAGED STANDBY DATABASE D
Tue Jun 24 17:03:46 2008
Fetching gap sequence for thread 1, gap sequence 14660-14679
Trying FAL server: sta2201f.dpa.km.sta.ua
Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14660.001
Media Recovery Log C:\ORACLE\ORADATA\MB\MB_ARCHIVE\ARC14661.001

recover managed standby database cancel;
shutdown immediate
startup nomount
alter database mount standby database;
recover managed standby database disconnect from session;

Параметр fal_client, действительно, появился в oracle 9.2. Цитирую:"New initialization parameters: REMOTE_ARCHIVE_ENABLE, FAL_CLIENT, FAL_SERVER, STANDBY_FILE_MANAGEMENT, ARCHIVE_LAG_TARGET". Смотрите здесь здесь

C ORACLE случайностей не бывает. по поводу FAL_SERVER и FAL_CLIENT вы совершенно правы.

Опыта создания стэндбая с горячей копии, то есть когда промышленная база находится в онлайн, у меня нет. Но есть информация, что это возможно в оракле 10g с использованием Enterprise Manager и RMAN. Успехов!

если архивлоги переданы на стэндбай, но не накатаны, то на праймари эти архивлоги удаляются командой delete obsolete. По крайней мене, так на девятке.

В каком виде формируются журналы повторного выполнения можно почитать в моей статье "Содержимое журналов повторного выполнения" в разделе "журналы повторного выполнения" (http://my-oracle.it-blogs.com/post-153.aspx). Об UNDO напишу несколько постов в ближейшее время. Расчитываю на Ваше внимание.

В sqlplus нужно писать так:

ALTER SYSTEM SWITCH LOGFILE;

или

ALTER SYSTEM SWITCH LOGFILE

/

В ответ на команду ALTER SYSTEM SWITCH LOGFILE; оракл или выдает сообщение об ошибке, или переключает журналы, или зависает в ожидании, потому что не может журналы переключить

REDO не отключается в принципе. Если формируется малый объем redo, значит в большом размере журнальных файлов нет необходимости. К сведению , redo формируется на все (блоки данных и undo сегменты), что находятся в буферном кэше и изменяется. А зачем в вашем случае вообще нужен ORACLE?

Увы, пакет DBMS_SCHEDULER входит в состав Oracle Database 10g. В состав Oracle Database 9i входит пакет DBMS_JOB.

Приятно, что Вам понравилась статья. Будем рады, если она пригодится Вам в работе.

Самый простой способ:на клиенте создайте папку, сделайте доступ к ней (для начала, всем - всё).Затем создайте объект DIRECTORY на сервере :create or replace directory LOAD_DIR as '\\сетевое_имя_клиента\шара\'; Пакетом UTL_FILE прямо в эту directory формируйте файл. Если у Вас Oracle Database 10g, то вы можете работать с пакетом DBMS_SCHEDULER, который может выполнять команды ОС. Успехов!

Например, trunc(sysdate+1)+2.5/24

Если речь идет о том, чтобы следующий запуск задания происходил только лишь после того, как завершится текущий запуск этого же задания, то так в оракле и происходит. Если же речь идет о последовательном выполнении различных заданий, то можно попробовать выставить параметр JOB_QUEUE_PROCESSES в значение равное 1. В этом случае запустится один фоновый процесс. Скорее всего этот процесс может работать только с одним задание. Пробуйте. Очень надеюсь,что Вы нам сообщите о результатах изысканий. Успехов!

Это поле interval и должно быть типа varchar2. А для чего его преобразовывать в тип дата?

Конечно можно. При условии, что у вас параметр JOB_QUEUE_PROCESSES установлен в значение достаточное для одновременного запуска нескольких заданий.Наверняка долженбыть больше 1.

параметр INTERVAL установите в значение sysdate + 1/48

По поводу первого вопроса: что собой представляет redo-запись лучше всего видно в дампе. Выполните команду, например, ALTER SYSTEM DUMP LOGFILE 'K:\oracle\oradata\my_db\redo01.log'. B папке user_dump_dest посмотрите полученый файл. Картина прояснится. По поводу второго вопроса: RBA (Redo Byte Address) -КАЖДАЯ redo-запись имеет этот адрес, который определяет её начало. В нём НЕ содержится адреса изменяемого блока. По поводу третьего вопроса. Думаю, когда Вы посмотрите дамп своего редо лога, то первая часть вопроса отпадет. по поводу оставшейся части: почитайте мой пост http://my-oracle.it-blogs.com/post-69.aspx, там немного розписано для чего нужна undo информация в redo логах. И не забывайте, что восстановление возможно на любой момент в прошлом.В этом случае также не обойтись без undo информации.

По поводу восстановления по времени: если у Вас версия ниже 10g, то есть такая команда recover database until time. Для версии 10g и выше там совсем другая история: там возможен как накат вперед так и назад. Теперь относительно Block cleanout record.Это, скорее всего, отложенная очистка блока. Чтобы с этим разобраться, опять советую почитать статью Скулкина Дмитрия Управление пространством внутри блока данных. А так же мой очень-очень упрощенный пост Очистка блоков данных. В тему,наверное, будет еще и пост Типы блокировок , так как Block cleanout record появляется, когда ITL(список заинтересованных транзакций), который находится в заголовке блока, не обновился, хотя транзакция завершилась.

Это немного разные таблички.

begin insert into temp_table SELECT * FROM TABLE (MY_FUNCTION('MY_TABLE')) where 1=1; end;

Благодарю за подсказку. По поводу RMAN - некоторым любителям оракла, как и мне в том числе, религия не позволяет его использовать. А по поводу RECOVER DATABASE USING BACKUP CONTROLFILE приведу цитату:Control files play a crucial role in database restore and recovery. For databases running in ARCHIVELOG mode, Oracle recommends that you back up control files with the ALTER DATABASE BACKUP CONTROLFILE TO 'filename' statement. If you back up the control file with an operating system utility during a closed, consistent whole database backup, then you should only use this control file when restoring the other datafiles taken in the backup. Although a control file backed up with an operating system utility during a consistent backup can sometimes be used for recovery (but only if you specify the USING BACKUP CONTROLFILE clause of the RECOVER statement), Oracle does not recommend this practice because neglecting to specify the USING BACKUP CONTROLFILE clause can cause recovery problems."

Вы, конечно же, правы. Каждый САМ выбирает путь и несет ответственность за свою базу.

Создали эту таблицу. Процесс пошел дальше, но не надолго: файл трассировки показал, что еще одной таблицы нет. Решили, что это процесс бесконечный. Видно, оракл поставили некорректно. Сделали холодный бекап. Переустановили софт, подняли базу.Хорошо что это можно было сделать - база тестовая. Все ок.

Если до сих пор она не была нужна ораклу, то,думаю, что и пустой она может быть.

Буферный кэш блоков данных ( data block buffer cache)-это кэш области SGA, используемый для хранения блоков данных, которые считываются из сегментов данных: из таблиц, индексов и кластеров.

Блоки данных распределяются по бакетам в зависимости от формулы bucket#=mod(DBA,_db_block_hash_buckets). Изходя из неё можно сделать вывод, что распределение зависит только от file# и block#. Если учесть, что количество бакетов в 2 раза больше размера кэша, то предполагается, что каждая цепочка в основном состоит из одного блока и , при необходимости, его CR-"копий".

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

Изменения сделаны. Благодарю за внимание к моим постам. Надеюсь на Ваше участие и в дальнейшем.

Всегда рады!

и RMAN тоже.

Например, http://ora-code.com/

Вы правы. Ваш запрос проще. Но одинаков ли результат?

Настаиваю - результат этих двух запросов не одинаков! Обратите внимание, что Ваш запрос выдает не только пользовательские запросы.

Супер! осталось еще отбросить свой запрос и тогда результат будет идентичным.

конечно, на сервере.

можно утилитой oradim.exe А можно и через "управление компьютером" - "службы и приложения" - "службы"

Пробуйте работать, например, с такими запросами :

select * from v$sysstat where name like '%parse%'
select sid,name,a.value from v$sesstat a,v$statname b where name like '%parse%' and a.statistic#=b.statistic#

Конечно,Вы правы. Только по представлению v$session нужно найти sid нашей мертвой сессии.Спасибо!

data_object_id - номер объекта словаря данных для сегмента, содержащего объект. object_id - номер объекта словаря данных для объекта

стандбай работает без USE_SHARED_SOCKETS = TRUE, только с исключениями по порту 1521 и по программе oracle.exe. Проверить клиентские подключения сейчас невозможно.Когда найдется подходящий сервер, то проверю. С разделяемыми серверами сейчас не работаю. sorry! Если у Вас есть информация - поделитесь. Наверное, многим интересно будет.

Это вдохновляет. Пожалуй,я тоже займусь блогом ! а то последнее время все более важные дела находятся. Спасибо Вам!

Выше написано:"Для баз данных, работающих в режиме разделяемых (shared) соединений по-прежнему действуют параметры sort_area_size, sort_area_retained_size и др., а pga_aggregate_target игнорируется.". Или Вы не об этом спрашивали?

SORRY! У меня по этому поводу нет никакого опыта.

зайдите в наш раздел "Вопросы и ответы" - там есть похожая ситуация. http://my-oracle.it-blogs.com/questions.aspx

Вы, конечно же , правы. Но я знаю наверняка, что еще до сих пор успешно експлуатируются версии ORACLE<=8 на небольших серверах.

рекламирует DBMS_SPACE.UNUSED_SPACE, показывает неиспользуемое пространство в сегментах

чем плохо резервировать место , но его не использовать? Табличные пространства немеряно растут. Самый простой способ борьбы: импорт-экспорт с перенастройкой таблиц и индексов.

а как в этом случае перенастроить свойства таблиц и индексов?

Для primary и standby требуются одинаковые платформы, ос, и версии оракла. Это связано требованиями к одинаковости структур файлов базы данных. С Suse не довелось работать. Поэтому сказать ничего не могу. Пробуйте! Интересно было бы разобраться в этом контексте с logical standby database.

Этот запрос отрабатывает на ORA10g без проблем. На 9-ке попробуйте так:select KSPPINM,KSPPDESC,KSPPSTVL,KSPPSTDF from X$KSPPSV a,x$ksppi b where a.indx=b.indx and KSPPINM like '_db_always_check_system_ts'

Вы указали очень полезную ссылку.Том Кайт показывает как он упаковывает архивные файлы на сервере, который генерирует архивные файлы ( то есть не на STANDBY). Отличие состоит в следующем: на standby нужно проверять, накатился ли архивный файл, который собираемся удалять; на основной базе проверяется завершен ли процесс архивации файла, который упаковывается.

snap_end и snap_begin - Не поля! это номера ваших "снимков". их нужно указывать по факту. ПОчитайте документацию по STATSPACK