<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-1333774174880496722</id><updated>2012-01-25T05:37:40.981+02:00</updated><category term='SQLTXPLAIN'/><category term='LOB'/><category term='DML'/><category term='concurency'/><category term='bind variable'/><category term='RAC'/><category term='LIO'/><category term='check constraint predicate'/><category term='bind peeking'/><category term='index'/><category term='HASH JOIN'/><category term='Sampling'/><category term='DBMS_XPLAN'/><category term='cardinaliry feedback'/><category term='RLS'/><title type='text'>SQL Tuning: practice and annotations</title><subtitle type='html'>Cитуации из жизни, эксперименты, исследования на тему настройки производительности СУБД Oracle.</subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>24</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-8688538777989344023</id><published>2011-08-23T20:56:00.000+03:00</published><updated>2011-08-23T20:56:29.726+03:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='concurency'/><title type='text'>TM enqueue with mode=3</title><summary type='text'>There is yet another case when INSERT statement can be blocked.
According to this Oracle doesn`t acquire table locks on the child table during insert into parent table. But I`ve discovered something else.

Suppose you have a MASTER table and a DETAIL table with UNINDEXED foreign key constraint which references the MASTER table. Foreign key has been created with ON DELETE CASCADE option. And there</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/8688538777989344023/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=8688538777989344023' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8688538777989344023'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8688538777989344023'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2011/08/tm-enqueue-with-mode3.html' title='TM enqueue with mode=3'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-8185628978259770199</id><published>2011-07-27T10:45:00.000+03:00</published><updated>2011-07-27T10:45:11.081+03:00</updated><title type='text'>Hint no_query_transformation in select statement with union</title><summary type='text'>Recently I have worked on huge sql query which was made up from several unioned subqueries.
My colleagues and I managed to parallelise job of tuning that query. Each of us worked on a single subquery.
After we had finished I collected all rewritten subquery and tried to run the whole sql.
But something went wrong. It seemed that some of subqueries changed its plans after they had been united into</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/8185628978259770199/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=8185628978259770199' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8185628978259770199'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8185628978259770199'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2011/07/hint-noquerytransformation-in-select.html' title='Hint no_query_transformation in select statement with union'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-1538337775769410589</id><published>2011-01-17T11:42:00.000+02:00</published><updated>2011-01-17T11:42:47.468+02:00</updated><title type='text'>Has FIRST ROW optimization taken place</title><summary type='text'>How to identify does the CBO use FIRST ROW optimization for a given query?
I ran into this question several days ago when I was tuning a pagination query. 
I received a plan with COUNT STOPKEY operator which was right above VIEW operator. 

------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/1538337775769410589/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=1538337775769410589' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1538337775769410589'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1538337775769410589'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2011/01/has-first-row-optimization-taken-place.html' title='Has FIRST ROW optimization taken place'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-2195198628378541821</id><published>2010-12-15T16:15:00.000+02:00</published><updated>2010-12-15T16:15:50.791+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='bind variable'/><title type='text'>Quick search of queries without binds</title><summary type='text'>Reading the Oracle Performance tuning guide put in my head an idea about how to find queries which are used literals instead of binds. We can use fact that such queries usually share their plans.

SQL&gt; set pages 9999
SQL&gt; set lines 140
SQL&gt; column sql_text format a80
SQL&gt; select plan_hash_value, sql_text, sql_id, executions
  2    from v$sql x
  3   where plan_hash_value in (select </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/2195198628378541821/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=2195198628378541821' title='Комментарии: 1'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/2195198628378541821'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/2195198628378541821'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2010/12/quick-search-of-queries-without-binds.html' title='Quick search of queries without binds'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-6504830176496655902</id><published>2010-10-08T13:29:00.000+03:00</published><updated>2010-10-08T13:29:40.670+03:00</updated><title type='text'>Preparing a tablespace to become read only</title><summary type='text'>Now I am reading the Oracle Database Administrator's Guide 11g Release 2 (11.2). And I have found some interesting detail here. That chapter says about preparing a tablespace to move in readonly state. And it proposes to take some action for doing blocks cleanout. But documentation suggests using something like this "select count(*) from table". It is not enough! Make sure Oracle really scans </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/6504830176496655902/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=6504830176496655902' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/6504830176496655902'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/6504830176496655902'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2010/10/preparing-tablespace-to-become-read.html' title='Preparing a tablespace to become read only'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-4920086076522262306</id><published>2010-05-31T11:28:00.002+03:00</published><updated>2010-05-31T12:52:27.326+03:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='index'/><category scheme='http://www.blogger.com/atom/ns#' term='LIO'/><category scheme='http://www.blogger.com/atom/ns#' term='DML'/><title type='text'>DML through indexes</title><summary type='text'>Recently I have been rereading Effective Oracle by Design. And I realized something new for myself.
Inter alia I reread "Modification DML from Start to Finish" section:

In general, these statement have a query component...
In general, a modification statement will find data it needs to update using the consistent-read mechanism described in the previous section. Then it will get that information</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/4920086076522262306/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=4920086076522262306' title='Комментарии: 1'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4920086076522262306'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4920086076522262306'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2010/05/dml-through-indexes.html' title='DML through indexes'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-1961987938536324799</id><published>2010-03-06T13:30:00.002+02:00</published><updated>2010-03-06T13:33:44.238+02:00</updated><title type='text'>ORA-08006</title><summary type='text'>I have observed a lack information about ORA-08006 in world wide web.
I am want to show yet another one case with situation that produces such error.
You can trap the ORA-08006 if your code meet following conditions:
you have got some kind of ETL engine and it work pattern is: insert row if it new (exists in source and does not exist in target), update row if it already exists and delete row in </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/1961987938536324799/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=1961987938536324799' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1961987938536324799'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1961987938536324799'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2010/03/ora-08006.html' title='ORA-08006'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-2240333894950175159</id><published>2009-12-02T21:49:00.004+02:00</published><updated>2009-12-03T21:00:24.986+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cardinaliry feedback'/><title type='text'>Data generator</title><summary type='text'>Yesterday I had fallen to new issue with bad performance of "reusable code". It was some piece of code seemed to be very elegant from programmer point of view.Complicated select statement contained the some kind of "data generator" as inline view like following:select add_months(:p_begin_date, level - 1) dt  from dualconnect by level &lt; months_between(:p_end_date, :p_begin_date) + 2This subquery </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/2240333894950175159/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=2240333894950175159' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/2240333894950175159'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/2240333894950175159'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/12/data-generatot.html' title='Data generator'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-7423541133006732865</id><published>2009-11-28T22:41:00.003+02:00</published><updated>2009-11-29T07:32:27.634+02:00</updated><title type='text'>Reusable program code</title><summary type='text'>I had finished the first stage of highly intensive performance tuning project yesterday. I had found the problem that is very illustrative for statement about "poor effectiveness of universal program code". In my case it was reusable code of "individual calculations" that have been reused in "mass calculations". This is mistaken itself. But another effect had took place in the run time. It was </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/7423541133006732865/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=7423541133006732865' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7423541133006732865'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7423541133006732865'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/11/reusable-program-code.html' title='Reusable program code'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-4467337160998666933</id><published>2009-11-19T14:53:00.010+02:00</published><updated>2009-11-29T07:36:18.063+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='RAC'/><title type='text'>Parameter File Search Order in Oracle RAC</title><summary type='text'>It is still not documented or rather poorly documented thing about "Parameter File Search Order in Oracle RAC". Even documentation release 11.2 continue to assert the following:Oracle Database searches for your parameter file in a particular order depending on your platform.On Linux and UNIX platforms, the search order is as follows:  1. $ORACLE_HOME/dbs/spfilesid.ora  2. $ORACLE_HOME/dbs/</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/4467337160998666933/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=4467337160998666933' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4467337160998666933'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4467337160998666933'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/11/parameter-file-search-order-in-oracle.html' title='Parameter File Search Order in Oracle RAC'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-42053849470965022</id><published>2009-10-09T14:40:00.004+03:00</published><updated>2009-11-29T07:35:59.414+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='DBMS_XPLAN'/><category scheme='http://www.blogger.com/atom/ns#' term='RAC'/><title type='text'>DBMS_XPLAN.DISPLAY_CURSOR for RAC database.</title><summary type='text'>I had the two-node Oracle RAC till recently. And it was sufficient to use the dbms_xplan.display_cursor function to examine the query execution plans with run-time statistics with connection to required instance.However, recently my oracle databases have migrated onto new hardware with eight nodes. It is become inconveniently to use dbms_xplan.display_cursor for examination of all instances and </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/42053849470965022/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=42053849470965022' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/42053849470965022'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/42053849470965022'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/10/dbmsxplandisplaycursor-for-rac-database.html' title='DBMS_XPLAN.DISPLAY_CURSOR for RAC database.'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-3205889171613670544</id><published>2009-05-29T10:45:00.025+03:00</published><updated>2009-06-02T20:42:15.242+03:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='HASH JOIN'/><title type='text'>Представления словаря данных</title><summary type='text'>Преамбула: когда-то давно, лет пять назад, я стоял у истоков одной большой информационной системы, был ее архитектором. Сейчас занимаюсь поддержкой и развитем этой системы. В основе выбранной мною архитектуры лежало понятие изолированных подсистем, каждая подсистема находится в отдельной схеме базы данных. Экземпляр системы состоит из набора схем, имеющих дозированный доступ друг к другу. Кроме </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/3205889171613670544/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=3205889171613670544' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/3205889171613670544'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/3205889171613670544'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/05/blog-post.html' title='Представления словаря данных'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-4531421581652107485</id><published>2009-01-01T20:47:00.021+02:00</published><updated>2009-01-04T18:33:42.586+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Sampling'/><title type='text'>The use of statistically incorrect assumptions when using this feature can lead to incorrect or undesirable results</title><summary type='text'>В описании sample_clause для select statement имеется такое предупреждение:Caution:The use of statistically incorrect assumptions when using this feature can lead to incorrect or undesirable results.Чем это может "грозить"?Всем известный dbms_stats широко использует sample_clause при вычислении статистических показателей. При использовании параметров сбора статистики по умолчанию возможны </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/4531421581652107485/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=4531421581652107485' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4531421581652107485'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4531421581652107485'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2009/01/use-of-statistically-incorrect.html' title='The use of statistically incorrect assumptions when using this feature can lead to incorrect or undesirable results'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-4458629655642834606</id><published>2008-12-28T20:46:00.008+02:00</published><updated>2009-01-12T16:29:37.443+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cardinaliry feedback'/><title type='text'>Древовидные справочники в качестве таблиц-размерностей или анализ “что-если” применительно к “TUNING BY CARDINALITY FEEDBACK METHOD”</title><summary type='text'>Недавно консультировал коллегу по настройке запроса. Суть решаемой запросом задачи состояла в следующем: таблица фактов (далее facts) связана с таблицей размерности (далее dic$territory), а та в свою очередь, являлась древовидным справочником административно-территориального устройства. Интересующий моего коллегу запрос должен был выдавать некоторые суммарные значения по таблице facts, </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/4458629655642834606/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=4458629655642834606' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4458629655642834606'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/4458629655642834606'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/12/tuning-by-cardinality-feedback-method.html' title='Древовидные справочники в качестве таблиц-размерностей или анализ “что-если” применительно к “TUNING BY CARDINALITY FEEDBACK METHOD”'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-190247331296695920</id><published>2008-11-16T20:12:00.035+02:00</published><updated>2009-09-21T18:03:12.078+03:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='LOB'/><title type='text'>Работаем с BLOB</title><summary type='text'>Недавно принимал участие в решении проблемы низкой производительности PL\SQL приложения. Анализ файла трассировки 10046 навел на мысль о том, что в основном код работает с BLOB-данными. Разработчики подтвердили это предположение. Соответствующий фрагмент отчета tkprof приведен ниже:declare  a blob;begin  a:=PrintActiveContragent(7720);end;call     count       cpu    elapsed       disk      query</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/190247331296695920/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=190247331296695920' title='Комментарии: 1'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/190247331296695920'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/190247331296695920'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/11/blob.html' title='Работаем с BLOB'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-3428324187020317817</id><published>2008-10-28T22:06:00.048+02:00</published><updated>2009-01-04T18:26:14.838+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='bind peeking'/><title type='text'>Неудачные значения при bind peeking.</title><summary type='text'>Проводя ежедневный осмотр моей боевой БД, обнаружил долгоиграющий запрос. На 3 запуска более 80000 секунд времени исполняния (по данным v$sql). Естественно, не дожидаясь отклика "благодарных" пользователей начал исследовать это явление.Промышленная база версии 10.2.0.4.Для иллюстрации буду использовать вот такие тестовые данные:create table t1 as select * from all_objects;create table t2 as </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/3428324187020317817/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=3428324187020317817' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/3428324187020317817'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/3428324187020317817'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/10/bind-peeking.html' title='Неудачные значения при bind peeking.'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-6630532591498912360</id><published>2008-06-25T14:42:00.004+03:00</published><updated>2009-01-04T18:26:42.253+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='check constraint predicate'/><title type='text'>Предикат из чек-констрейнта</title><summary type='text'>Еще одна, очевидно, ошибка, связанная со сгенеренными предикатами.drop table ch1;create table ch1 (f1 number(1) constraint ch1_ck_f1 check (f1 in ('1','2','3')));insert into ch1 values (1);insert into ch1 values (2);insert into ch1 values (3);insert into ch1 values (4);commit;exec dbms_stats.gather_table_stats(ownname=&gt;null,tabname=&gt;'ch1')select * from ch1 where f1=1;explain plan for select * </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/6630532591498912360/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=6630532591498912360' title='Комментарии: 1'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/6630532591498912360'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/6630532591498912360'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/06/blog-post.html' title='Предикат из чек-констрейнта'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-9086297897631824397</id><published>2008-06-25T11:14:00.011+03:00</published><updated>2009-01-04T18:26:58.862+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='cardinaliry feedback'/><title type='text'>Tuning by Cardinality Feedback в действии</title><summary type='text'>В свое время, статья Tuning by Cardinality Feedback произвеля на меня неизгладимое впечатление.И вот теперь случилось применить ее в одном интересном случае. Вот такой план имел место быть на промышленной площадке.Сразу же бросается в глаза серъезное расхождение между прогнозом оптимизатора и статистикой времени исполнения. Первая стадия анализа привела к фрагменту плана, в котором, как мне </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/9086297897631824397/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=9086297897631824397' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/9086297897631824397'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/9086297897631824397'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/06/tuning-by-cardinality-feedback.html' title='Tuning by Cardinality Feedback в действии'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-1681877780692195850</id><published>2008-06-17T22:00:00.010+03:00</published><updated>2009-01-04T18:27:19.252+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='SQLTXPLAIN'/><title type='text'>Этот замечательный инструмент SQLTXPLAIN</title><summary type='text'>В ноте 215187.1 среди прочего упоминается замечательный инструмент SQLTXPLAIN - незаменимая штуковина для аналитика.После нескольких запусков я обнаружил маленькую неприятную деталь при использовании режима XTRACT: ORA-07445: caught exception [ACCESS_VIOLATION] at [_msqsub()+23].Проверял на версии 10.2.0.1 (Linux 32 bit), а также на 11.1.0.6 (Win32).Похоже, что ошибка возникает в процессе </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/1681877780692195850/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=1681877780692195850' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1681877780692195850'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/1681877780692195850'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/06/sqltxplain.html' title='Этот замечательный инструмент SQLTXPLAIN'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-7013515212097352905</id><published>2008-03-08T15:02:00.004+02:00</published><updated>2009-01-04T18:28:34.390+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Sampling'/><title type='text'>SQL Profile - some habits</title><summary type='text'>Click here for access scripts and results of experiments with SQL Tuning Task.This is a supplementary for my questions in Jonathan Lewis`s article "SQL Profiles - 2"</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/7013515212097352905/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=7013515212097352905' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7013515212097352905'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7013515212097352905'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2008/03/sql-profile-some-habits.html' title='SQL Profile - some habits'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-7692563518578950446</id><published>2007-09-10T10:01:00.001+03:00</published><updated>2009-01-04T18:29:12.528+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='LIO'/><title type='text'>Задача о поиске свободного слота (дискуссия программистов, работающих с MySQL и Oracle)</title><summary type='text'>Решение задачи возможно с использованием двух подходов: 1) «универсальный» или «независимый от платформы» (а, скорее, продиктованый возможностями, например, MySQL); 2) с использованием возможностей конкретной СУБД (в данном случае, естесственно, речь пойдет об Oracle).Исходные данные:SQL&gt; select * from v$version;BANNER----------------------------------------------------------------Oracle Database</summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/7692563518578950446/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=7692563518578950446' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7692563518578950446'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/7692563518578950446'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2007/09/mysql-oracle.html' title='Задача о поиске свободного слота (дискуссия программистов, работающих с MySQL и Oracle)'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-978533285836594579</id><published>2007-08-14T14:09:00.001+03:00</published><updated>2009-01-04T18:29:27.009+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='RLS'/><title type='text'>Стоимость Row Level Security</title><summary type='text'>Комментируя статью, я подумал о том, что хорошо бы попытаться простым экспериментом оценить стоимость использования, так сказать, Row Level Security (RLS, DBMS_RLS). Причем, сделать оценку с точки зрения использования защелок (latch), поскольку, похоже, именно они являются причиной проблем на нагруженных многопользователями системах, использующих RLS (по крайней мере я с такими проблемами </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/978533285836594579/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=978533285836594579' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/978533285836594579'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/978533285836594579'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2007/08/row-level-security.html' title='Стоимость Row Level Security'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-650160718404295060</id><published>2007-06-22T15:16:00.001+03:00</published><updated>2009-01-04T18:29:49.715+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Sampling'/><title type='text'>Использование dynamic sampling с временными таблицами</title><summary type='text'>Следующая проблема - тоже из практики. Другой мой коллега написал здоровенную хранимую процедуру, делающую обширные вычисления неких социальных показателей. Она интенсивно использует временные таблицы для хранения промежуточных результатов, по мере ее работы в несколько временных таблиц постепенно вставляется по нескольку десятков тысяч строк. При этом, по ходу вычислений, временные таблицы по </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/650160718404295060/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=650160718404295060' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/650160718404295060'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/650160718404295060'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2007/06/dynamic-sampling.html' title='Использование dynamic sampling с временными таблицами'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-1333774174880496722.post-8500948497270900948</id><published>2007-06-20T14:45:00.001+03:00</published><updated>2009-01-04T18:30:18.452+02:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='LIO'/><title type='text'>Агрегаты в один проход</title><summary type='text'>Обратился недавно ко мне мой коллега за помощью по настройке запроса. Тот запрос состоял из двух частей: 1) tab2 - соединение 5 таблиц, таких соединений было два, объединенных оператором union, вся эта конструкция предоставляла исходные данные для агрегации; 2) tab1 - "синтетическая" таблица, поставляющая 17 строк - показателей агрегации. Указанные две части соединялись и к результату соединения </summary><link rel='replies' type='application/atom+xml' href='http://practical-sql-tuning.blogspot.com/feeds/8500948497270900948/comments/default' title='Комментарии к сообщению'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=1333774174880496722&amp;postID=8500948497270900948' title='Комментарии: 0'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8500948497270900948'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/1333774174880496722/posts/default/8500948497270900948'/><link rel='alternate' type='text/html' href='http://practical-sql-tuning.blogspot.com/2007/06/blog-post_19.html' title='Агрегаты в один проход'/><author><name>YuriAP</name><uri>http://www.blogger.com/profile/14781383870484872725</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='24' src='http://bp3.blogger.com/_9QEFwbh2jiE/SFlOpmJCcTI/AAAAAAAAADA/zmSnPFWPmUg/S220/P8170090.JPG'/></author><thr:total>0</thr:total></entry></feed>
