dbstalker Profile

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

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

А если попробовать так: 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]?

Да, Вы правы. Там,действительно, без иерархий. Но, если Вы обратили внимание, там ограниченное число строк превращается в ограниченное число столбцов. Если Вы уже подняли вопрос транспонирования таблицы, то могу вам посоветовать еще один мой пост <a href="http://my-oracle.it-blogs.com/post-75.aspx";>Как транспонировать таблицу в ORACLE?</a>. Благодарю за внимание к моему блогу!

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

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

Запрос на выборку НЕ провоцирует генерацию 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

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

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

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

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

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

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;

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

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

ALTER SYSTEM SWITCH LOGFILE;

или

ALTER SYSTEM SWITCH LOGFILE

/

Увы, пакет 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

По поводу первого вопроса: что собой представляет 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(список заинтересованных транзакций), который находится в заголовке блока, не обновился, хотя транзакция завершилась.

Благодарю за подсказку. По поводу 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-"копий".

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

Всегда рады!

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

Для 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 нужно проверять, накатился ли архивный файл, который собираемся удалять; на основной базе проверяется завершен ли процесс архивации файла, который упаковывается.