Another possible issue that I have come across is when you want to create the deployment script. At stage 2 of the Generate Scrip, I cannot scroll across this field to see the full location and file name, for example
C:\Users\btierney\Documents\9.Downloads\Apps\Oracle SQL Developer\sqldeveloper-18.104.22.168.27-no-jre\sqldeveloper\sqldeveloper\bin
I only get the following on screen
C:\Users\btierney\Documents\9.Downloads\Apps\Oracle SQL Developer\sqldeveloper-22.214.171.124.27-no-jre\sqldevelo
I cannot scroll across to get the rest
The event handling errors would not affect the behavior of the product but should still be fixed so I have filed bug 17191918 .
As for performance differences:
1) If you install the data miner repository on 126.96.36.199 or above it will run match faster.
ODMr uses a different XMLDB storage implementation in 188.8.131.52 above.
In DBs prior to 184.108.40.206, XMLDB OR storage is used whereas in 220.127.116.11 and above XMLDB Binary storage is used.
The performance of the Binary implementation is significantly faster than OR for ODMr's xml schema definition and overall implementation.
I don't mean for this to be a knock on OR, it is just that Binary is now a much better fit for ODMr.
For 18.104.22.168 and earlier, as newer versions of the repository are installed, the complexity of the schema for the workflow documents increases, which also increases the overhead of processing.
So we clients to move forward to either upgrade to 22.214.171.124 or 12.1 to improve performance.
2) I don't know of any global issues in SQL Dev that would affect performance across the board.
You could consider adding more memory allocation to the SQL Dev Virtual Machine.
This can be done by editing the ide.conf file in the C:\<Install Directory>\sqldeveloper\ide\bin directory to increase the memory.
Here are some instructions from the ide.conf file:
# If you are getting the 'Low Memory Warning' Message Dialog while running
# JDeveloper, please increase the -Xmx value below from the default 800M to
# something greater, like 1024M or 1250M. If after increasing the value,
# JDeveloper is no longer starting up because it fails to create a virtual
# machine, then please reduce the modified -Xmx value, or use a 64bit JDK
# which allows for very very large value for -Xmx.
3) Does a new Explore Node running any faster then an existing Explore Node that was migrated?
I would not expect so.
4)To actually see the run times for the nodes, you can right click the node and select Show Event Log.
You can then click on the Info icon on the grid tool bar to display information event logs that contain run time information for specific tasks accomplished by the node.
I'll have a look at the memory allocation to SQL Dev to see if that makes a difference.
The change in performance of the Explore node is a bit of a surprise. I've done lots of ODM demos over the years and I've always included the Explore Node. It did run quickly (30 seconds) previous to the upgrade on the same data. I'm running 126.96.36.199. So it is a bit surprising the difference in time. It now takes 5 minutes, for the same data and database. So based on this timing I cannot use it in a demo. Some of the build nodes are doing more processing and there is very little difference in timings. This is good.
There is no difference in timing between a newly created Explore node and an Explore node that was migrated.
What about existing customers who are using ODM. Should they stay with SQL Dev 3 until they can upgrade to 188.8.131.52 or 12.1? for performance reasons. Also to consider the number of customers who have just moved to or are currently moving 11 and it will be some time before they will looking at 12
Any idea of a time frame when will 184.108.40.206 be available?
I haven't gotten to testing ODM on 12.1 yet. I'll be doing that testing over the weekend
Message was edited by: Brendan
When I run the Explore Node using MINING_DATA_BUILD_V on 220.127.116.11 it takes 26 seconds. So there does seem to be something about your configuration. Are you running in 32 or 64 bit mode at the client?
We do not expect users to hit the type of performance problem you have.
I will try a test on a upgrade ODMRSYS repository on 18.104.22.168 and see if I can recreate this condition.
Do you recall what the history of your repository is?
For example, did you originally install SQl Dev 3.0 and then do upgrades from that point on, or was the repository loaded fresh using SQL Dev 3.2 and then upgraded to 4.0 from there?
This will help me recreate the same migration path to see if it makes any difference.
Interesting. That is the timing I was expecting-ish.
Typical it might be something to do with me so
I started with SQL Dev 3 and upgraded with each release and EAs
I've tried it again and this time it took 6 minutes. From watching the Workflow Jobs progress bar it get to the 3/4 point quickly and then spends the rest of the time (approx 5.25 minutes) at this point before completing.
It seems to be something just before or starting the cleanup
Event Job Node Sub Node Time Message Duration END(WORKFLOW) ODMR$WFJOB4368 19/07/13 22:02:15 D:0 H:0 M:6 S:17 END(CLEANUP) ODMR$WFJOB4368 19/07/13 22:02:15 D:0 H:0 M:0 S:0 START(CLEANUP) ODMR$WFJOB4368 19/07/13 22:02:14 END(NODE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:57:18 D:0 H:0 M:0 S:45 END(STATISTICS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:57:18 D:0 H:0 M:0 S:23 END(CREATE HISTOGRAMS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:57:14 D:0 H:0 M:0 S:9 START(CREATE HISTOGRAMS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:57:06 END(CREATE EXPLORE STATISTICS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:57:06 D:0 H:0 M:0 S:11 START(CREATE EXPLORE STATISTICS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:55 START(STATISTICS) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:55 END(CREATE HISTOGRAM SAMPLE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:55 D:0 H:0 M:0 S:0 START(CREATE HISTOGRAM SAMPLE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:54 END(CREATE SAMPLE DATA) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:54 D:0 H:0 M:0 S:13 START(CREATE SAMPLE DATA) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:42 END(SAMPLE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:38 D:0 H:0 M:0 S:0 START(SAMPLE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:38 END(VALIDATE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:38 D:0 H:0 M:0 S:6 START(VALIDATE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:38 START(NODE) ODMR$WFJOB4368 Explore Data 1 19/07/13 21:56:38 END(NODE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:25 D:0 H:0 M:0 S:20 END(SAMPLE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:25 D:0 H:0 M:0 S:13 START(SAMPLE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:12 END(VALIDATE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:12 D:0 H:0 M:0 S:7 START(VALIDATE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:11 START(NODE) ODMR$WFJOB4368 MINING_DATA_BUILD_V1 19/07/13 21:56:11 START(WORKFLOW) ODMR$WFJOB4368
Is there are way to automatically expand the all the Workflow Editor tabs, or is there a setting to do this. Otherwise I have to expand them each time I go into ODM. I should have asked for/about something like this before now.
I've make the memory changes to the SQL Dev VM as you suggested and it seems to have made a difference and getting the response that I'm used to.
Message was edited by: Brendan
My mind has been niggling away all weekend about the performance issue. I keep on thinking we had similar discussions for a previous release.
When using the Predictive Query node (against a 12c DB) when I press F1 or click on the help button I get, No help topic available.
Can you point me to where I can see the new feature Prediction Result Explanation.
When dropping the repository from the 12.1 I get the following in SQL Dev4
DMUSER:SQL Developer:SQL Developer:USER:257:317:INACTIVE
Message was edited by: Brendan
There seems to be some inconsistency with the Components Workflow Editor.
It happens when I'm expanding each of the options. I use the mouse to adjust the height for each option and it appears that sometimes the icons get reduced in size with maybe 3 being displayed per line. Then sometimes they go to 4 per line.
So we can end up with some icons having a different size for one option (e.g. Models) and icons for another option (e.g. Predictive queries) having a different size.
I don't notice any changes in size of icons. I do notice that you could trigger a vertical scroll bar to be introduced into one of the categories, if you fail to provide sufficient space to display it.
This could reduce that categories ability to display as many components per line.
I see this gap of time in the event log, between the Explore Node end event and the start of the workflow cleanup event.
Could be Oracle Scheduler held off on allowing the workflow clean up step to be run.
If you have OEM running on your db, you might be able to gain more information by monitoring the workflow via the Oracle Scheduler interface.