recover database until time '2008-12-11:12:00:00' using backup controlfile;

Tue, 16 Dec 2008 00:00:00 GMT

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

На другом сервере создали базу с таким же именем. Новую базу остановили. Далее файлы данных, файл инициализации, файл паролей подменили.Так как управляющие файлы были потеряны вместе с базой, пришлось использовать управляющие файлы из бекапа.


startup mount
recover database until time '2008-12-11:12:00:00' using backup controlfile;
alter database open resetlogs;

База открылась и все ок.

В очередной раз об ORA-00600: internal error code, arguments: [12700].А также ORA-01498: block check failure

Tue, 25 Nov 2008 00:00:00 GMT

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

Предлагаю действовать так: SELECT owner, object_name, object_type, object_id, data_object_id FROM dba_objects WHERE data_object_id = 58262 – это число из сообщения об ошибке.
Таким образом, узнали с каким объектом проблемы.

Если проблемы в индексе, то тут легко и просто. Удалили и пересоздали.

Если это таблица, то есть несколько вариантов:
- попробуем сберечь информацию из таблицы: create table my_temp_table as select * from my_table_corrupt; Затем поломанную таблицу удаляем и создаем вновь из нашей временной.
- Поменяем только характеристики блоков данных (см здесь). Например, alter table my_table_corrupt pctfree хх, pctused хх; alter table t move;
- можно попробовать перенести в другое табличное пространство alter table t move tablespace tbs_new;

Если из этих относительно хороших вариантов ничего не сработало, то пробуем дальше:

ANALYZE TABLE [название поломанного объекта] VALIDATE STRUCTURE;
ANALYZE TABLE [название поломанного объекта] VALIDATE STRUCTURE CASCADE.

И если мы получим здесь сообщение - ORA-01498: block check failure - see trace file, то поступим так, как советует здесь Donald K. Burleson

А именно:


DBMS_REPAIR.CHECK_OBJECT
=========================

CHECK_OBJECT procedure checks the specified object and populates the repair
table with information about corruption and repair directive(s).  Validation
consists of block checking all blocks in the object.  All blocks previously
marked corrupt will be skipped.

Note: In the initial release of DBMS_REPAIR the only repair is to mark the 
      block as software corrupt.

SQL> @checkObject
SQL> set serveroutput on
SQL>
SQL> declare
  2    rpr_count int;
  3  begin
  4    rpr_count := 0;
  5  dbms_repair.check_object (
  6    schema_name => 'SYSTEM',
  7    object_name => 'T1',
  8    repair_table_name => 'REPAIR_TABLE',
  9    corrupt_count => rpr_count);
10    dbms_output.put_line('repair count: ' || to_char(rpr_count));
11  end;
12  /
repair count: 1

PL/SQL procedure successfully completed.

SQL> desc repair_table
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
OBJECT_ID                                NOT NULL NUMBER
TABLESPACE_ID                            NOT NULL NUMBER
RELATIVE_FILE_ID                          NOT NULL NUMBER
BLOCK_ID                                  NOT NULL NUMBER
CORRUPT_TYPE                              NOT NULL NUMBER
SCHEMA_NAME                              NOT NULL VARCHAR2(30)
OBJECT_NAME                              NOT NULL VARCHAR2(30)
BASEOBJECT_NAME                                    VARCHAR2(30)
PARTITION_NAME                                    VARCHAR2(30)
CORRUPT_DESCRIPTION                                VARCHAR2(2000)
REPAIR_DESCRIPTION                                VARCHAR2(200)
MARKED_CORRUPT                            NOT NULL VARCHAR2(10)
CHECK_TIMESTAMP                          NOT NULL DATE
FIX_TIMESTAMP                                      DATE
REFORMAT_TIMESTAMP                                DATE

SQL> select object_name, block_id, corrupt_type, marked_corrupt,
  2  corrupt_description, repair_description
  3  from repair_table;

OBJECT_NAME                      BLOCK_ID CORRUPT_TYPE MARKED_COR
------------------------------ ---------- ------------ ----------
CORRUPT_DESCRIPTION
--------------------------------------------------------------------------------
REPAIR_DESCRIPTION
--------------------------------------------------------------------------------
T1                                      3            1 FALSE
kdbchk: row locked by non-existent transaction
        table=0  slot=0
        lockid=32  ktbbhitc=1
mark block software corrupt

ORA-1991 Database mounted in Exclusive Mode. Как побороть?

Thu, 06 Nov 2008 00:00:00 GMT

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


Database mounted in Exclusive Mode.
ORA-1991 signalled during: alter database mount exclusive...

Решить эту проблему помогло пересоздание парольного файла:


orapwd file=C:\oracle\ora92\database\pwdmydb.ora password=sys entries=2

Oracle Listener crash in Windows или о том, что лучше выполнить одну команду, чем ОС переустанавливать.ORA-12520

Thu, 06 Nov 2008 00:00:00 GMT

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

ОС - WINXP SP2.Сообщения были по поводу проблем с Oracle Listener – сейчас не могу точно вспомнить, какое именно сообщение было об ошибке. Очень долго не могли разобраться, в чем дело. Во всех оракловский протоколах не могли найти никакого внятного объяснения такой ситуации. Пришлось переустанавливать операционку и оракл. Как потом оказалось, что можно было обойтись всего лишь командой:


netsh winsock reset catalog

Нашли мы это здесь. На другом сервере в этом же филиале проверили.

P.S. Сегодня запускали в промышленную эксплуатацию новый сервер на Microsoft Windows Server 2003 R2 Server 5.2 Service Pack 2 (32-bit). Через несколько часов работы, когда число юзеров начало немеряно расти, начали вылазить ошибки:

ORA-12520: TNS:listener could not find available handler for requested type of server

воспользовались изложеным выше рецептом.Помогло.

Cache buffer chains. Логическое чтение (LIO) - это плохо?

Tue, 28 Oct 2008 00:00:00 GMT

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

Но бывают такие ситуации, что логическое чтение - это зло. Это случается тогда, когда большое число логический чтений приводит к избыточному использованию CPU и защелок, к конкуренции за защелки. А это в свою очередь приводит к росту ожиданий серверных процессов и, значит, наш пользователь ощущает явное замедление работы своего приложения. И ему как-то все равно, что наш buffer hit ratio равен 100%. Вся наша оптимизация оказалась безрезультативной. В тоже время стоит заметить, что конкуренция за защелки – явление весьма редкое, говорящее о неувязках при выполнении кода, либо о большом количестве процессов, в одно и тоже время выполняющих одинаковые действия. О том насколько дорого логическое чтение, стоит ли бороться с физическим чтением, как уменьшить избыточное чтение прочитайте в замечательной статье Why You Should Focus on LIOs Instead of PIOs .Cary Millsap/Hotsos Enterprises, Ltd.

А дальше, немного в нашем контексте о Cache buffer chains.

Давайте вспомним о защелках, групповых защелках, буферном кэше, x$bh, цепочках блоков и все с этими понятиями связанное.

Предположим, что наша база стала «тормозить», с помощью нехитрых манипуляций (v$latchholder,v$latch_children (miss , sleeps), v$system_event, V$SESSION_WAIT, V$SESSION_WAIT_HISTORY) удалось выяснить – непомерно поднялся уровень CBC (Cache buffer chains). Что это означает?

Дальше идут личные мои умозаключения, поэтому к ним прошу относиться очень осторожно, скептически.

Блоки в буферном кэше организованы в цепочки, каждая цепочка имеет защелку. Если очень многим пользователям в одно и тоже время нужен один и тот же блок или блоки, которые находятся в одной цепочке, вот в этих случаях и наблюдается высокий уровень Cache buffer chains. То есть все наши пользователи борются за одну защелку, стерегущую цепочку блоков. Если буфер данных у Вас большой, то, возможно, в цепочке находится один блок. Значит, в этом случае все сражаются за один блок (но тогда растет еще и buffer busy waits). Возможен также вариант, что Вы очень значительно увеличили размер буферного кеша, а число защелок _db_block_hash_latches осталось прежним. Поэтому цепочки образовались достаточно длинными, следовательно, поиск по ним значительно увеличился по времени, а это привело к возникновению конкуренции.

Или, например, неэффективный план запроса спровоцировал излишнее LIO: из-за неподходящего индекса серверный процесс сначала читает блоки, а затем выясняется (после использования фильтра), что эти блоки нам не нужны. Хотя интенсивно потреблялись ресурсы: CPU, защелки.

Наши дальнейшие действия должны быть направлены на уменьшение LIO. Для начала найдем объекты с горячими блоками:


select bh.tch,bh.tim,object_.owner,object_.object_name,object_.object_type
from x$bh bh,v$latch_children l_c,dba_objects object_  
where owner not in ('SYS','SYSMAN') and l_c.name = 'cache buffers chains' and tch<>0 and bh.obj=object_.data_object_id and bh.hladdr = l_c.addr 
order by 1 desc

Я не удивлюсь, если этим объектом окажется sys.dual! Классический пример: использование без особой надобности select sysdate from dual или select seq_my.nextval from dual.

Предположим, что нашли объекты с горячими блоками. С помощью v$sqlarea ищем запросы, вызвавшие работу с «горячими» блоками.Следующий запрос может быть Вам полезным в этом:


select tch,owner,object_name,sql_text from v$sqlarea s,
(select * from (select bh.tch,bh.tim,object_.owner,object_.object_name,object_.object_type
from x$bh bh,v$latch_children l_c,dba_objects object_  
where owner not in ('SYS','SYSMAN','SYSTEM') and l_c.name = 'cache buffers chains'and object_.object_type='TABLE'
 and tch>10 and bh.obj=object_.data_object_id and bh.hladdr = l_c.addr order by tch desc) where rownum<10) b
where instr(s.sql_text,object_name)>0

А дальше возможны варианты:

менять запросы.
менять среду выполнения этих запросов.

По поводу первого варианта: идти по этому пути самое правильное решение. Оптимизация запросов, приводящих к избыточному логическому чтению - это и есть лечение болезни. Методы борьбы с этим явлением: проанализировать план выполнения запроса, а далее - переписать запрос, добавить/изменить индексы, настроить запросы с помощью hint , возможно стабилизировать план запроса.

После проработки первого варианта или когда нет возможности корректировки запросов, можно приступить и ко второму варианту.

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

Увеличивать число защелок?
Увеличивать (уменьшить – поможет в незначительном числе случаев) размер буферного кэша? (Может дать увеличение числа хэш бакетов, а если увеличить до более, чем 2048М, то и число защелок увеличится. Таким образом, произойдет изменение перераспределения блоков в цепочках, цепочки уменьшатся.)
Работать над параметрами db_block_hash_latches,db_block_hash_buckets?
Если проблемы вызваны непомерной нагрузкой на индекс (index root), то значение _db_handles_cached с 5 поменять на 10?
Изменять pctfree, inittrans в объектах с горячими блоками? (Уменьшит число записей в блоке)
Пытаться использовать пулы KEEP/RECYCLE?
Сделать перемещение таблицы /реблид индекса? (чтобы изменились адреса составляющих его блоков).
alter session set events 'immediate trace name flush_cache'; ? (Недокументированное очищение кэша буферов. Будьте осторожны!!!!)
Изменить PGA_AGGREGATE_TARGET?
Установить space_management=auto ?
Пробовать сегментировать, использовать блоки разного (как правило, меньшего) размера для горячих объектов?
Попробовать использовать реверсивные индексы (reverse)? В индексе с обращением ключа (reverse-key index) применяется обращение байтов индексируемой колонки числового типа. Этот прием позволяет получать равномерное распределение значений колонок среди блок-листов индекса со структурой B-Tree. Этот индекс хорошо подходит для индексирования колонок с последовательной нумерацией или нумерацией с заданным шагом. Заметим, что такие индексы применяются только для возвращения отдельных строк, и с их помощью нельзя выполнить поиск значений в некотором диапазоне. Вы не можете применить опцию REVERSE к битовым индексам и исключительно индексным таблицам.

Отвечать на все эти вопросы ВАМ. Будьте осторожны! Решение за Вами.

Обязательно учтите мнение Тома Кайта:

Latch: cache buffers chains

Possible Causes

Repeated access to a block (or small number of blocks), known as a hot block
From AskTom:

Contention for these latches can be caused by:

Very long buffer chains.
very very heavy access to the same blocks.

Possible Suggestion

From AskTom:

When I see this, I try to see what SQL the waiters are trying to execute. Many times, what I find, is they are all running the same query for the same data (hot blocks). If you find such a query -- typically it indicates a query that might need to be tuned (to access less blocks hence avoiding the collisions).

If it is long buffer chains, you can use multiple buffer pools to spread things out. You can use DB_BLOCK_LRU_LATCHES to increase the number of latches. You can use both together.

The cache buffers chains latches are used to protect a buffer list in the buffer cache. These latches are used when searching for, adding, or removing a buffer from the buffer cache. Contention on this latch usually means that there is a block that is greatly contended for (known as a hot block).

To identify the heavily accessed buffer chain, and hence the contended for block, look at latch statistics for the cache buffers chains latches using the view V$LATCH_CHILDREN. If there is a specific cache buffers chains child latch that has many more GETS, MISSES, and SLEEPS when compared with the other child latches, then this is the contended for child latch.

This latch has a memory address, identified by the ADDR column. Use the value in the ADDR column joined with the X$BH table to identify the blocks protected by this latch. For example, given the address (V$LATCH_CHILDREN.ADDR) of a heavily contended latch, this queries the file and block numbers:


SELECT OBJ data_object_id, FILE#, DBABLK,CLASS, STATE, TCH
FROM X$BH
WHERE HLADDR = 'address of latch'
ORDER BY TCH;

X$BH.TCH is a touch count for the buffer. A high value for X$BH.TCH indicates a hot block.

Many blocks are protected by each latch. One of these buffers will probably be the hot block. Any block with a high TCH value is a potential hot block. Perform this query a number of times, and identify the block that consistently appears in the output. After you have identified the hot block, query DBA_EXTENTS using the file number and block number, to identify the segment.

After you have identified the hot block, you can identify the segment it belongs to with the following query:


SELECT OBJECT_NAME, SUBOBJECT_NAME
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = &obj;

In the query, &obj is the value of the OBJ column in the previous query on X$BH.

Why You Should Focus on LIOs Instead of PIOs .Cary Millsap/Hotsos Enterprises, Ltd. Отличная статья (полностью ее найдёте в сети). В статье Вы найдете ответы на многие вопросы. Во сколько операции ввода-вывода на диск медленнее, чем в памяти? Что такое «логическое чтение»? Насколько рентабельнее логическое чтение от физического? Стоит ли стремиться к тому, чтобы все необходимые блоки были в памяти? Как побороть излишнее LIO?

Executive Summary
Many Oracle educators teach that reducing the number of PIO calls should be the top priority of SQL optimization. However, in our field work, we commonly eliminate 50% or more of the response time from slow Oracle applications, even after they’ve been tuned to execute no PIO calls. The secret is that Oracle LIO calls are more expensive than many people understand. In this paper, I explain the following research results:

LIO processing is the number-one bottleneck for many business processes today, even on systems with “excellent” database buffer cache hit ratios.

Excessive LIO call frequency is a major scalability barrier, because LIOs consume two of the system’s most expensive resources: CPU and latches.

Even if you could have an infinite amount of memory and achieve a perfect 100% database buffer cache hit ratio, your system will be inefficient and unscalable if it executes more Oracle LIO calls than it needs to.

The statistics that database administrators commonly track can lead you to believe that PIO processing is your bottleneck when it’s not. Do not increase disk or memory capacity until after you determine the impact of PIO latency upon your end-user response times.

If you will focus on LIO reduction from the very beginning of a SQL optimization task instead of PIO reduction, then you will usually eliminate most of your PIOs by side-effect, because most of your PIOs are motivated by LIO calls in the first place.
…
How to Eliminate LIOs

When either CPU service or waits for “latch free” is a big part of your users’ response times, then you probably have an LIO problem. If you do, then the most economically efficient way to solve the problem is probably to optimize the SQL that causes too many LIOs. A high-LIO SQL statement running in one program at a time is a problem for one user who is waiting for the program’s output. It’s possibly a problem for other users as well, if they are competing for scarce CPU and latch resources with the high-LIO statement. A high-LIO statement running in dozens of concurrent programs is a catastrophic problem for everyone. In both problems, it is difficult to make any real progress by masking the issue by manipulating memory or disks. The permanent long-term solution is to eliminate unnecessary LIOs.

It’s not so hard to do. Step one: focus your attention upon LIO reduction, not PIO reduction. Stop measuring performance by watching your database buffer cache hit ratio, especially for individual SQL statements. When you look at tkprof output, pay attention to the query and current columns. When you look at v$sql, pay attention to the buffer_gets column. Don’t stop optimizing if a query consumes more than 100 LIOs per row returned,even if you’ve figured out how to reduce the PIO count for the query to zero. Lookups and simple joins should require fewer than 10 LIOs per row returned.

By eliminating LIOs first (before you try to reduce the PIO count), you will save time and money, because you’ll be reducing the fundamental unit of work in Oracle from which most resource consumption derives. Remember, a program can have a PIO count of zero and still run for hours. But a program with a low LIO count will consume only a small amount of CPU service, a small number of latch acquisitions, and of course a necessarily small number of PIOs as well, because a small number of LIOs will nearly always motivate only a small number of PIOs. Only after you have optimized the LIO requirement of an Oracle program should you consider a memory of disk upgrade. The query optimization software in the Oracle kernel gets smarter with every release (for an interesting article on this subject, see [Gorman 2001]). But still, the Oracle performance analyst will encounter systems in which the number one cause of performance trouble is poor query optimization. Some of the more common mistakes that we see in the field include:

Executing unnecessary business functions. There is no more efficient or effective system optimization technique than to determine that a business is expending scarce system resources to produce output that either nobody looks at, or output whose business function can be suitably replaced by less expensive output. Performance analysts who isolate themselves from the functional requirements of a business application also isolate themselves from opportunities to eliminate unnecessary business functions. To optimize workload, you must understand the business of that workload.

Carrying massive amounts of row source data through several stages of a complicated execution plan, only to filter out most of the rows in a late stage of the plan. Use hints and stored outlines if you must, but force Oracle to filter data as early in an execution plan as you can. The idea that all full-table scans are bad. Full-table scans are efficient in their place; use them when they are more efficient than index-driven plans. If you are in doubt about whether a full-table scan is efficient, test it.

The idea that all nested loops plans are good. Nested loops execution plans are notorious for driving “excellent” database buffer cache hit ratios, because they tend to revisit the same Oracle blocks over and over again. Replacing nested loops plans with other joins (full-table scans driving either hash joins or sort-merge joins, for example) can sometimes result in spectacular performance improvements.

Failure to use array processing. Fetching data one row at a time also drives “excellent” database buffer cache hit ratios, because they also tend to cause Oracle to revisit the same blocks over and over again. Using Oracle array operations will reduce not only LIO frequencies, but often enormous amounts of network traffic as well.

Conclusion

In system optimization and capacity planning exercises since 1990, several of my colleagues and I have created reliable SQL performance forecasts by using the assumption that a LIO+PIO operation costs about 100 times as much as a bare LIO. However, many people believe that the relative cost is 10,000-to-1. Fortunately, the average latencies of LIO+PIO and bare LIO for an Oracle session are simple to compute. In this paper, I have explained how to use easily obtainable operational data to determine for certain which ratio is closer to the truth. In 71 trace files uploaded to www.hotsos.com, the relative performance difference is only a factor of 37. The average LIO latency in our test data is about 50 microseconds; that is, Oracle LIOs execute at a typical pace of only about 20,000 per second. The average PIO latency in our data is about 2 milliseconds, which is faster than typical disk hardware latencies because of the effects of various I/O subsystem memory buffers.

The “myth of 10,000” is more than just an inconsequential technical detail. The myth is dangerous because it motivates performance analysts to make a dreadful mistake: to assume that you can optimize a system by eliminating PIOs. On the contrary, the most important optimization goal for the Oracle performance analyst is to reduce LIO counts. Even if you could install 1-millisecond disks and an infinite amount of memory for your database buffer cache, your Oracle system performance would be constrained as it probably is now, by the CPU capacity required to process all of your application’s LIO calls.

In the field, Oracle performance analysts who focus on LIO reduction routinely eliminate 50% or more of the CPU and elapsed time required to perform key business functions. Not only does LIO call reduction yield a beneficial impact upon CPU consumption, but it eliminates potentially large segments of user response time wasted on “latch free” events. Even systems with no PIO calls can waste tens of hours of CPU time per day if they execute too many LIO calls. Ironically, systems with extremely high (99%+) database buffer cache hit ratios are especially good can-didates for LIO call reduction

Cursor_sharing='FORCE' - удивительные последствия: rows will be truncated

Mon, 06 Oct 2008 00:00:00 GMT

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

conn sys/пароль@строка_коннекта as sysdba alter system set cursor_sharing=’FORCE’; set linesize 90 select ‘1111111111’,’1111111111’ from dual; select rpad( ‘1111111111’,10) test1,rpad(’2222222’,10) test2,rpad(’333333’,10) test3 from dual; SQL> conn sys/ пароль@строка_коннекта as sysdba Connected. SQL> alter system set cursor_sharing='FORCE'; System altered. SQL> set linesize 90 SQL> select '1111111111','1111111111' from dual; '1111111111' '1111111111' -------------------------------- -------------------------------- 1111111111 1111111111 SQL> select rpad( '1111111111',10) test1,rpad('2222222',10) test2,rpad('333333',10) test3 from dual; TEST1 ------------------------------------------------------------------------------------------ TEST2 ------------------------------------------------------------------------------------------ TEST3 ------------------------------------------------------------------------------------------ 1111111111 2222222 333333

Получается, что если к столбцу применяется rpad, то значение столбца выводится с новой строки.
conn sys/ пароль@строка_коннекта as sysdba alter system set cursor_sharing=’FORCE’; set linesize 90 SET WRAP OFF Set TrimSpool ON select ‘1111111111’,’1111111111’ from dual; select rpad( ‘1111111111’,10) test1,rpad(’2222222’,10) test2,rpad(’333333’,10) test3 from dual; SQL> conn sys/ пароль@строка_коннекта as sysdba Connected. SQL> alter system set cursor_sharing='FORCE'; System altered. SQL> set linesize 90 SQL> SET WRAP OFF SQL> Set TrimSpool ON SQL> select '1111111111','1111111111' from dual; '1111111111' '1111111111' -------------------------------- -------------------------------- 1111111111 1111111111 SQL> select rpad( '1111111111',10) test1,rpad('2222222',10) test2,rpad('333333',10) test3 from dual; rows will be truncated rows will be truncated TEST1 ------------------------------------------------------------------------------------------ 1111111111

А если использовать WRAP OFF, то, вообще, выводится в спул только первый столбец и сообщение "rows will be truncated".Изменим параметр: cursor_sharing=’EXACT’
conn sys/ пароль@строка_коннекта as sysdba alter system set cursor_sharing=’EXACT’; set linesize 90 SET WRAP OFF Set TrimSpool on select ‘1111111111’,’1111111111’ from dual; select rpad( ‘1111111111’,10) test1,rpad(’2222222’,10) test2,rpad(’333333’,10) test3 from dual; SQL> conn sys/ пароль@строка_коннекта as sysdba Connected. SQL> set linesize 90 SQL> SET WRAP OFF SQL> Set TrimSpool on SQL> select '1111111111','1111111111' from dual; '111111111 '111111111 ---------- ---------- 1111111111 1111111111 SQL> select rpad( '1111111111',10) test1,rpad('2222222',10) test2,rpad('333333',10) test3 from dual; TEST1 TEST2 TEST3 ---------- ---------- ---------- 1111111111 2222222 333333
При таком значении параметра cursor_sharing в спул выводится все корректно. Чудеса!

Убить неактивные сессии! Параметр resource_limit.

Fri, 11 Jul 2008 00:00:00 GMT

На одном подшефном сервере работаю нерадивые пользователи: подключаются к серверу с утреца и идут курить на несколько часиков. Научить их жизни не получается. Пришлось побороть их следующим образом:
Alter system set resource_limit=true scope=both; ALTER PROFILE "DEFAULT" LIMIT IDLE_TIME 15;
Всем пользователям назначили этот профиль.Таким образом ограничили «курение» 15 минутами. Злостные «курильщики» получают сообщение: ORA-02396: exceeded maximum idle time, please connect again

ARCHIVELOG или NOARCHIVELOG? Вот в чем вопрос?

Mon, 07 Jul 2008 00:00:00 GMT

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

Выполните следующий запрос, чтобы знать режим работы ваше базы:
select log_mode from v$database;
При эксплуатации базы данных в режиме NOARCHIVELOG формируются данные для восстановления лишь при сбое экземпляра (instance recovery) – оперативные журналы повторного выполнения. Такая ситуация возникает, например , при отключении питания.

При эксплуатации базы данных в режиме ARCHIVELOG формируются данные для восстановления как при сбое экземпляра (instance recovery), так и при сбое носителя (media recovery) – оперативные и архивные журналы повторного выполнения.

Каждый способ имеет преимущества и недостатки (см. таблицу). Поэтому администратору приходится самому решать проблему выбора.

ARCHIVELOG NOARCHIVELOG

Дополнительная нагрузка на сервер + -

Восстановление без потерь данных + -

Горячее резервное копирование + -

Возможность создания «горячей» резервной базы данных (standby) + -

Восстановление на указанный момент времени + -

Instance recovery + +

Media recovery + -

Необходимость наличия носителей больших объемов + -

Главное:

В режиме noarchivelog восстановление возможно только на момент создания последнего бэкапа.

В режиме archivelog восстановление возможно до момента времени последней фиксации транзакции.

Важно: если не делать бэкапы, то режим archivelog вообще не имеет смысла, так как восстановление происходить путем применения архивных журналов к последнему корректному бэкапу(накат вперед).

Мое решение: тестовая база – NOARCHIVELOG; промышленная – ARCHIVELOG. И будь почти спокоен!

DROP USER . ORA-00604: error occurred at recursive SQL level 1 ORA-00942: table or view does not exist

Tue, 17 Jun 2008 00:00:00 GMT

На одном из подопечных серверов нужно было удалить пользователя. Но на команду DROP USER my_user cascade было получено сообщение: «ORA-00604: error occurred at recursive SQL level 1 ORA-00942: table or view does not exist».
Ничего лучшего не могли придумать, как только получить файл трассировки:
alter session set sql_trace=true; DROP USER my_user cascade;
Снова получаем ошибку: ORA-00604: error occurred at recursive SQL level 1 ORA-00942: table or view does not exist

Но теперь имеем файл трассировки. В нем находим :
PARSE ERROR #15:len=78 dep=1 uid=0 oct=7 lid=0 tim=677704568731 err=942 delete from system.aq$_internet_agent_privs WHERE db_username = NLS_UPPER(:1) EXEC #1:c=1203125,e=19331497,p=60,cr=902,cu=0,mis=0,r=0,dep=0,og=4,tim=677704635416 ERROR #1:err=604 tim=67771625 STAT #2 id=1 cnt=0 pid=0 pos=1 obj=3475 op='TABLE ACCESS FULL OBJ#(3475) '
Как оказалось, таблички system.aq$_internet_agent_privs как раз и не было в этой базе данных.

Вывод:

Файл трассировки - это хорошо!

ORA-01578: ORACLE data block corrupted (file # string, block # string)

Wed, 02 Apr 2008 00:00:00 GMT

На сервере 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; Пострадал индекс. Удалили его и создали заново. Все завершилось успешно.

	ARCHIVELOG	NOARCHIVELOG
Дополнительная нагрузка на сервер	+	-
Восстановление без потерь данных	+	-
Горячее резервное копирование	+	-
Возможность создания «горячей» резервной базы данных (standby)	+	-
Восстановление на указанный момент времени	+	-
Instance recovery	+	+
Media recovery	+	-
Необходимость наличия носителей больших объемов	+	-