<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Oracle Designer &#8211; on Design Editor performance and Repository Maintenance</title>
	<atom:link href="http://technology.amis.nl/2004/10/26/oracle-designer-on-design-editor-performance-and-repository-maintenance/feed/" rel="self" type="application/rss+xml" />
	<link>http://technology.amis.nl/2004/10/26/oracle-designer-on-design-editor-performance-and-repository-maintenance/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=oracle-designer-on-design-editor-performance-and-repository-maintenance</link>
	<description></description>
	<lastBuildDate>Fri, 12 Apr 2013 10:04:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Ken Are Astrup</title>
		<link>http://technology.amis.nl/2004/10/26/oracle-designer-on-design-editor-performance-and-repository-maintenance/#comment-999</link>
		<dc:creator>Ken Are Astrup</dc:creator>
		<pubDate>Fri, 29 Oct 2004 09:45:45 +0000</pubDate>
		<guid isPermaLink="false">/?p=224#comment-999</guid>
		<description><![CDATA[Oops!
I am sorry, i had a momentary memory lapse. You have to disregard my two previous comments.
I mixed up the performance problems in Design Editor with another performance problem with that I was working on.

BTW, Design Editor is NOT using RULE hint in general. Only in very few cases.

This time I have checked the document i wrote!
This is the findings:

1. When opening a folder in DE, a select is issued which check if there exists objects under the nodes (eg. Modules, Relational Tables and so on). I guess it is to determine if the nodes should be expandable.
2. When opening a node (eg. Modules)
2a. DE issues a select to find all the modules in that folder. On our system this select took about 10 seconds. This select will profit from that there is fewer rows in the folder_member table.
2b. Then for each module, it issues one select to get more info about each module. Its like Forms issuing post-query triggers to get lookup values for each row. Each of these selects took from 0.05 to 0.1 seconds. Now, if there is 700 modules as we have and the average for each select is 0.075 seconds. The sum of these selects is about 52.5 seconds. If you include the first select that finds all the modules, it takes 1 minute and 2.5 seconds to open the module node in my example. So you are obviously right about reducing the number of objects in each folder. RON is not issuing these selects, thats the reason why it is that much quicker.]]></description>
		<content:encoded><![CDATA[<p>Oops!<br />
I am sorry, i had a momentary memory lapse. You have to disregard my two previous comments.<br />
I mixed up the performance problems in Design Editor with another performance problem with that I was working on.</p>
<p>BTW, Design Editor is NOT using RULE hint in general. Only in very few cases.</p>
<p>This time I have checked the document i wrote!<br />
This is the findings:</p>
<p>1. When opening a folder in DE, a select is issued which check if there exists objects under the nodes (eg. Modules, Relational Tables and so on). I guess it is to determine if the nodes should be expandable.<br />
2. When opening a node (eg. Modules)<br />
2a. DE issues a select to find all the modules in that folder. On our system this select took about 10 seconds. This select will profit from that there is fewer rows in the folder_member table.<br />
2b. Then for each module, it issues one select to get more info about each module. Its like Forms issuing post-query triggers to get lookup values for each row. Each of these selects took from 0.05 to 0.1 seconds. Now, if there is 700 modules as we have and the average for each select is 0.075 seconds. The sum of these selects is about 52.5 seconds. If you include the first select that finds all the modules, it takes 1 minute and 2.5 seconds to open the module node in my example. So you are obviously right about reducing the number of objects in each folder. RON is not issuing these selects, thats the reason why it is that much quicker.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Are Astrup</title>
		<link>http://technology.amis.nl/2004/10/26/oracle-designer-on-design-editor-performance-and-repository-maintenance/#comment-998</link>
		<dc:creator>Ken Are Astrup</dc:creator>
		<pubDate>Thu, 28 Oct 2004 14:47:36 +0000</pubDate>
		<guid isPermaLink="false">/?p=224#comment-998</guid>
		<description><![CDATA[A few clarifications.

1. The folder_member table is a link between a version of a folder and a version of a object.
2. Why it helps to purge the insignificant versions of the folder? The folder_members of the insignificant folder versions will be deleted as well. It will reduce the size of the folder_member table dramatically.]]></description>
		<content:encoded><![CDATA[<p>A few clarifications.</p>
<p>1. The folder_member table is a link between a version of a folder and a version of a object.<br />
2. Why it helps to purge the insignificant versions of the folder? The folder_members of the insignificant folder versions will be deleted as well. It will reduce the size of the folder_member table dramatically.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Are Astrup</title>
		<link>http://technology.amis.nl/2004/10/26/oracle-designer-on-design-editor-performance-and-repository-maintenance/#comment-997</link>
		<dc:creator>Ken Are Astrup</dc:creator>
		<pubDate>Thu, 28 Oct 2004 14:40:06 +0000</pubDate>
		<guid isPermaLink="false">/?p=224#comment-997</guid>
		<description><![CDATA[I have investigated similar performance problems in a fairly large repository.

This is what i found.

If you use a sql sniffer (like Quest SQL Monitor) you can see that DE uses the RULE hint for queries against the database. RON does not use hints; it uses CBO.

The problem is that if your application system (or folder) has a great number of objects, and the folder exists in MANY versions.
For every version of the folder, all the objects in it is stored as a record in the FOLDER_MEMBER table.

Say that you have 1000 objects in the folder, and 100 versions of the folder. Only this folder will have 1 million rows in the FOLDER_MEMBER table. Considering the RULE hint, the database has to do full table scan. The result is terribly bad performance.

So what is the cure? Purge all insignificant versions of the folder.]]></description>
		<content:encoded><![CDATA[<p>I have investigated similar performance problems in a fairly large repository.</p>
<p>This is what i found.</p>
<p>If you use a sql sniffer (like Quest SQL Monitor) you can see that DE uses the RULE hint for queries against the database. RON does not use hints; it uses CBO.</p>
<p>The problem is that if your application system (or folder) has a great number of objects, and the folder exists in MANY versions.<br />
For every version of the folder, all the objects in it is stored as a record in the FOLDER_MEMBER table.</p>
<p>Say that you have 1000 objects in the folder, and 100 versions of the folder. Only this folder will have 1 million rows in the FOLDER_MEMBER table. Considering the RULE hint, the database has to do full table scan. The result is terribly bad performance.</p>
<p>So what is the cure? Purge all insignificant versions of the folder.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
