|DOAG 2013 Development in Bonn am 19. Juni
Am 19.Juni 2013 findet die nächste DOAG Development Konferenz in Bonn statt, diesmal mit dem Thema:
„Agile and Beyond – Projektmanagement in der Oracle-Softwareentwicklung“
Das Motto der zweiten Auflage der Community Konferenz steht fest: Die effektive Durchführung von Softwareprojekten steht thematisch im Zentrum der Konferenz für Entwickler, Softwarearchitekten und Projektleiter.
Gerade Oracle APEX eignet sich hervorragend für die agile Durchführung von Softwareprojekten, ich habe damit seit Jahren hervorragende Ergebnisse erzielt. Mit Oracle APEX kann man in extrem kurzen Iterationszyklen von 1-4 Wochen sehr beachtliche Funktionalitäten implementieren. Gerade die Lieferung von Funktionalitäten in kurzen Abständen hilft, das Vertrauen der Fachseiten zu gewinnen. Dennoch gibt es einige Fallstricke zu beachten, damit auch alles rund läuft ;).
Weitere Informationen zur Konferenz finden Sie hier
Bitte beachten: der Frühbucher-Rabatt endet heute!
get the Developer Toolbar back for mobile APEX Applications
When developing mobile applications with APEX 4.2 you’ll find the developer toolbar on the page bottom is missing.
This can be a little bit annoying when investigating misbehaving applications. Oracle recognizes this as Issue 14749955 with the workaround to access the toolbar functions through a desktop page…
Of course this is a bit annoying, so i spend some time and thought of a solution.
Here it is, a simple way to get the developer toolbar for mobile applications.
create a PL/SQL Region on the Global Page for mobile UI
Give the region a very high sequence number, something like 999999, to ensure it will be the last region in the body. As region template we are going to use “No Template”, since you don’t want to see any title for this region.
The region source will construct a nice horizontal button-group in mobile-friendly styling:
htp.p('<div data-role="controlgroup" data-type="horizontal" data-mini="true" id="apex-dev-toolbar">');
htp.p(' <a data-role="button" rel="external" href="f?p=4500:1000:'||APEX_APPLICATION.g_edit_cookie_session_id||'" title="Application Express Home">Home</a>');
htp.p(' <a data-role="button" rel="external" href="f?p=4000:1:'||APEX_APPLICATION.g_edit_cookie_session_id||'::NO:1,4150,RP:FB_FLOW_ID,FB_FLOW_PAGE_ID,F4000_P1_FLOW,F4000_P4150_GOTO_PAGE,F4000_P1_PAGE:&APP_ID.,&APP_PAGE_ID.,&APP_ID.,&APP_PAGE_ID.,&APP_PAGE_ID." title="Application &APP_ID.">Application &APP_ID.</a>');
htp.p(' <a data-role="button" rel="external" href="f?p=4000:4150:'||APEX_APPLICATION.g_edit_cookie_session_id||'::NO:1,4150:FB_FLOW_ID,FB_FLOW_PAGE_ID,F4000_P1_FLOW,F4000_P4150_GOTO_PAGE,F4000_P1_PAGE:&APP_ID.,&APP_PAGE_ID.,&APP_ID.,&APP_PAGE_ID.,&APP_PAGE_ID." title="Edit Page &APP_PAGE_ID.">Edit Page &APP_PAGE_ID.</a>');
htp.p(' <a data-role="button" rel="external" href="f?p=4000:336:'||APEX_APPLICATION.g_edit_cookie_session_id||'::NO::FB_FLOW_ID,FB_FLOW_PAGE_ID,F4000_P1_FLOW,F4000_P4150_GOTO_PAGE,F4000_P1_PAGE:&APP_ID.,&APP_PAGE_ID.,&APP_ID.,&APP_PAGE_ID.,&APP_PAGE_ID." title="Create">Create</a>');
htp.p(' <a data-role="button" rel="external" target="_blank" href="f?p=4000:34:'||APEX_APPLICATION.g_edit_cookie_session_id||':PAGE:NO:34:F4000_P34_SESSION,F4000_P34_FLOW,F4000_P34_PAGE,FB_FLOW_ID:&SESSION.,&APP_ID.,&APP_PAGE_ID.,&APP_ID.">Session</a>');
htp.p(' <a data-role="button" rel="external" href="f?p=4000:14:'||APEX_APPLICATION.g_edit_cookie_session_id||'::::FB_FLOW_ID,FB_FLOW_PAGE_ID,F4000_P1_FLOW,F4000_P4150_GOTO_PAGE,F4000_P1_PAGE:&APP_ID.,&APP_PAGE_ID.,&APP_ID.,&APP_PAGE_ID.,&APP_PAGE_ID." title="Caching">Caching</a>');
htp.p(' <a data-role="button" rel="external" target="_blank" href="f?p=4000:19:'||APEX_APPLICATION.g_edit_cookie_session_id||':::RIR,19:IR_APPLICATION_ID,IR_PAGE_ID:&APP_ID.,&APP_PAGE_ID." title="View Debug">View Debug</a>');
IF :DEBUG IS NULL OR :DEBUG = 'NO'
htp.p(' <a data-role="button" rel="external" href="f?p=&APP_ID.:&APP_PAGE_ID.:&SESSION.::YES" title="Debug">Debug</a>');
htp.p(' <a data-role="button" rel="external" href="f?p=&APP_ID.:&APP_PAGE_ID.:&SESSION.::NO" title="Debug">End Debug</a>');
Don’t forget to set the Condition to Type “PL/SQL Expression” and APEX_APPLICATION.g_edit_cookie_session_id IS NOT NULL, to guarantee this toolbar will show only for development session.
The end result is pretty slick, i think:
Of course this isn’t the “real” developer toolbar and it doesn’t support all the functions you are used, but it provides the necessary minimum (at least for me, it does).
Please let me know if this was helpful for you.
Announcing the EPM Oracle Mic Night at Kscope13
We want to hear from you! You'll have ten minutes to show everyone something awesome that you've done. Come out Monday night at Kscope and join us for a fun-filled, informative night!
Have you ever thought to yourself?
"I have this really neat thing that I am doing in Essbase (Planning, HFM, O
Getting to Know Your SIG Board
This month's featured board member:
Cessna Aircraft Company
Where did you grow up?
Damar, KS. Located in NW Kansas, it is a small town of about 150 people with strong French-Canadian heritage. My high school senior class (consolidated with two
EPM Tips and Tricks -- Know Your Support Resources
Oracle Support has gone out of their way to reach out to the EPM world through a wide variety of social media channels. What do I mean? How about:
What's New in Version 184.108.40.206
At a recent webcast presentation, Oracle introduced new content for the next major EPM release - the imminent "220.127.116.11." The products continue to offer improvements in performance and functionality, and this article attempts to summarize the most significant features from that presentation. (Of cou
ODTUG Kscope13: A Word from Our Sponsors
And Now for a Word from Our Sponsors (and Exhibitors)...
Vendors are an important part of Kscope13. You want to know about the products that are out there -- and they want to show them to you. So, in addition to the Exhibit Hall, we have one special session in the schedule for Vendor
gather_plan_statistics – 2
Some time ago – actually a few years ago – I wrote a note about the hint /*+ gather_plan_statistics */ making some informal comments about the implementation and relevant hidden parameters. I’ve recently discovered a couple of notes from Alexander Anokhin describing the feature in far more detail and describing some of the misleading side effects of the implementaiton. There are two parts (so far): part 1 and part 2.
Improving data move on EXADATA II
Writing log records
The last post in this series introduced the problem briefly. You find that post here.
In this post I’ll talk about the changes made to make that writing of log records fast enough. There were 50 million records that was written. Each of them pretty much in its own transaction. Of course the commit activity caused problem, as did log buffer issues. Some of this could be somewhat remedied with configuration.
The big issue though was that the writes themselves took too much time and too often many session ended up in long contention chains. Yes, it would have been great to have the luxury of redesigning the whole logging situation from the ground up. But, as is often the case, the solution was built such that all systems connecting were implemented in such a way that redesigning was not an option. Fixing the performance of this had to be done without requiring code changes to the systems performing the logging. Oh, joy.
So what caused the problem then? For the inserts it was pretty straight forward. Too many transactions making an insert and a commit. This caused indexes to be hotspots where all processes wanted to write at the same spot. Hash-partitioning had been introduced and that had led to less contention but slower performance. As the partitions existed on different parts on the disks the write head had to be constantly moved and that caused slower service times.
What could we do to make a big improvement while not affecting the code? We’re not talking about just 10-20% of improvement on any area in this case, and even more important was to make the performance stable. That is, the most important thing was to ensure that there were no spikes where an insert suddenly to 20 times longer than usual. The contention chains that was occurring made performance spike such that the whole system became unusable.
The solution here turned out to be something so far from advanced technologies as questioning assumptions. The first time I asked “why do we have these indexes”, most people in the room thought I was just joking around. Eventually they realised that I was serious. After an amusing period of silence where I could see them thinking “Do we need to inform him that indexes are needed to enforce uniqueness and to support referential integrity?”, someone went ahead and did just that. OK, now we were on to a productive discussion, as of course that wasn’t what I meant. The followup discussion about why we needed referential integrity and uniqueness for this set of data was very enlightening for everyone. To make a long story short, it was not needed at all. It was there because it had always been there and nobody had questioned the need before.
How come we didn’t need data to be unique? Well, this is log-data. That is it tells us what actions has been performed by the system. If some activity would be reported twice, it really wouldn’t be the end of the world. The possible problem that some activity isn’t logged cannot be handled with defining unique constraints. That is pure system design and nothing I could improve or worsen by removing some indexes.
Thus, the indexes was removed together with the foreign keys (referential integrity).
Sounds simple enough, but did it help? Did it ever! In one month after making the change, there has not been one report of one transaction that was anywhere close to take too long. This simple solution made the logging so fast that it is no longer a concern.
The next post in this series will discuss the solution for moving data to the history tables. This process took around 16 hours and it had to become at least three times as fast. As you’ll see, moving all these rows can be done much faster than so.