Book Review - iOS 5 Programming Cookbook

Ver este articulo en Español

You will write iOS apps in less than you think

Being a C/BASIC hardcore programmer for mobile devices in a past life, I enjoyed very much this book because it really helped me grasp quickly many basic and intermediate topics on iOS 5 Objective-C programming, would say after reading the full book I have all needed to program good basic applications; and even after getting practice and experience, guess I will eventually resort on this book as reference. In my opinion this book is awesome and a must for beginners and intermediates.

Honestly, I consider myself not very much fan to the Cookbook format, however this is one case where the author, Vandad Nahavandipoor, exploits it wonderfully to show and develop case after case of what you will face as an iOS programmer, both for iPad and iPhone! He misses nothing and includes good explanations and concise screenshots when needed.

Now, the table of contents covers almost everything is needed to develop any type of application: Location & Maps, Networking, Audio & Video, plus some “must-have” topics like Multitasking, Graphics & Animations or Core Motion. My favorite chapter is #2, because it provides the building blocks for GUI programming, including corresponding source code examples!

Something I would like to see is bluetooth or network programming basics, but maybe I'm overreaching and those are advanced topics, out of the scope if this book.

If you want to take a closer look go to the Product Page at O'Reilly website: iOS Programming Cookbook - Book I'm sure you will get interested!


Subscribe to Oracle Database Disected by Email Bookmark this on Delicious

Who is using your Undo space? - Improved Script

Ver este articulo en Español

Hi folks!
I have extended the Undo usage scripts to include two additional indicators:
1) undo change vector size statistics
2) Used undo records/blocks

and support for RAC infrastructure, so you can spot the hungriest UNDO eaters for any given instance.

Then the script for Oracle 11g is as follows:

set pagesize 400
set linesize 140
col name for a25
col program for a50
col username for a12
col osuser for a12
SELECT a.inst_id, a.sid, c.username, c.osuser, c.program, b.name,
a.value, d.used_urec, d.used_ublk
FROM gv$sesstat a, v$statname b, gv$session c, gv$transaction d
WHERE a.statistic# = b.statistic#
AND a.inst_id = c.inst_id
AND a.sid = c.sid
AND c.inst_id = d.inst_id
AND c.saddr = d.ses_addr
AND a.statistic# = 284
AND a.value > 0
ORDER BY a.value DESC

If you want to run this script on versions 10g1 and 10g2, just replace the statistic# with 176; 216 if your database is 11gR1... or use the following version independent script!!! (Hope we don't change the statistic name).

set pagesize 400
set linesize 140
col name for a25
col program for a50
col username for a12
col osuser for a12
SELECT a.inst_id, a.sid, c.username, c.osuser, c.program, b.name,
a.value, d.used_urec, d.used_ublk
FROM gv$sesstat a, v$statname b, gv$session c, gv$transaction d
WHERE a.statistic# = b.statistic#
AND a.inst_id = c.inst_id
AND a.sid = c.sid
AND c.inst_id = d.inst_id
AND c.saddr = d.ses_addr
AND b.name = 'undo change vector size'
AND a.value > 0
ORDER BY a.value DESC

Read the popular 2008 article Who is using your UNDO space?

Interested on MySQL Performance? Read  Book Review - High Performance MySQL


Subscribe to Oracle Database Disected by Email


Bookmark this on Delicious

First pervasive-post

Today I'm writing this post from a Samsung Galaxy, my hand sized tablet, camera included, microphone and lots of fun.

I have been busy this year and that is thanks to the tremendous success of the Database Machine/Exadata.

Traveled all over the caribbean and south america, plus my first OOW experience as Oracle employee: always exciting!

Bandeja Paisa / Paisa "tray" - Medellin, Colombia


Sao Paulo Subway System

Oracle Open World 2011

The Oracle Exadata: latest Business Weapon

Ver este articulo en Español

Sorry I’ve been having a lot of work installing, maintaining and migrating to Database Machines all over Latinamerica for the latest 10 months; that means lot of travels abroad, all of them very exciting, but the real excitement comes from my job working with this wonderful Machine.

Was on the last project when realized how important is this investment for our customers, having this big caribbean Telco installed their first Exadata and later migrated their databases meant for them dramatic performance improvements and the ability to get more up-to-date analytical information and compete better and more agile.

Of course the Database Machine fulfilled expectations when we achieved a processing reduction of 6x on their nightly batch processes, going from 8-9hrs processing time, down-to 1.5-2hrs processing time. What this means: now they’re able to increase the refreshing time of their analysis tools 12 times a day and on demand, instead of having latest information one day behind.

Read my related article on Exadata Hybrid Columnar Compression

My steps to implement EHCC

Recommended reading on My Oracle Support notes that helped make this happen:

Migrating to Oracle Exadata Storage Server Paper (PDF)

Oracle Sun Database Machine Performance Best Practices [ID 1067520.1]

Subscribe to Oracle Database Dissected by Email


Bookmark this on Delicious

My Steps to Implement Exadata EHCC

Ver este articulo en EspañolSubscribe to Oracle Database Disected by Email

Last time I was engaged with an Exadata migration, customer asked me about EHCC and how to implement it for their datamarts.

My approach (at that time) consisted on the following:
1) Get a sample of very big objects to play with
2) Used DBMS_COMPRESSION in order to get estimations for compression rates
3) Try every compression type: Basic, Query Low, Query High, Archive Low, Archive High and recorded size reductions, time to import and time for FTS.
4) Recorded and compared timings for various batch processes and important queries

With all those statistics, went to the customer and then he was able to take a decision based on nature of data, popular timeframe of querying within the data window, parallel degree, partitioning defined (BTW customer already had it on place, best practice!), and so on.

I've used Datapump to import because it uses direct path load and Basic compression needs it to kick in.

Further thinking on this matter resulted on proposals to include table usage (V$SEGMENT_STATISTICS) & table data dynamics (Monitoring+DBA_TAB_MODIFICATIONS) in order to fine tune the compression mode selected. The next time I've the opportunity to include this on the process, I'll share with you the results...

Thank you very much for your time, and if you liked this post please share with others freely...



Bookmark this on Delicious

From 3Tb to 1.5Tb Using standard COMPRESS and PCTFREE

Ver este articulo en Español

I've been working on a migration project, with very aggressive dates and a couple of requirements that increase difficulty: switch from filesystem to ASM, using 50% of new storage... yes, you got the right picture, we don't have full set of disks for ASM to fit all data, therefore I need to move data trying to release complete datafiles in order to free those logical volumes or LUNs, and later add them to ASM.

Anyway, I realized that given this is a DSS or Datawarehouse, there is some margin to increase "data density" per block, in other words decrease the amount of space within one data block that is wasted reducing PCTFREE.

Another opportunity to decrease storage usage came from the fact customer is upgrading from 10.2.0.4 to 11.1.0.7, so I can use STANDARD improved compression features on DATA!!!

The final touch came from a long time (and some times under-used feature), Index Key Compression. If you want more detail, can see my posts back from 2008 about this feature Index Key Compression - part I, Index Key Compression - part II and Index Key Compression - part III. Well, thanks the customer provided an environment dedicated to this project I was able to start doing som very expensive analysis on Index compression, with this strategy on mind: choose the biggest indexes to compress, then doing the ANALYZE INDEX ... VALIDATE STRUCTURE OFFLINE and SELECT * FROM INDEX_STATS for each candidate. (Please note you can consider not only massive indexes, but those heavily used too... for that you need to get usage info from V$SEGMENT_STATISTICS). Some indexes compressed very well, with 40%-50% space savings, while others didn't got that good rates on 4% or 6%, just depends on information nature/distribution.

First got all my tables with current allocated space, from DBA_SEGMENTS, filled one spreadsheet with this info and considered extra columns for PARALLEL degree for movement and compression flag, and so on. Using a formula was able to get 3000+ statements like this one:


ALTER TABLE ... MOVE PCTFREE 2 TABLESPACE DAT_ASM_HP NOLOGGING COMPRESS PARALLEL 8;

or like this one for indexes:

ALTER INDEX ... REBUILD TABLESPACE IDX_AHP COMPRESS 1 PARALLEL 8 NOLOGGING PCTFREE 2;


Well, final figures were:

Tables Starting:1.9Tb Ending:1Tb
Indexes Starting:1.0Tb Ending:0.5Tb

I have to remark that this space reductions:
1) Depend on this particular data distribution or patterns
2) After index rebuild, with time flowing and info gets inserted, Indexes will tend to "stabilize" and make block splits thus free space. (see this post on Index Dynamics)
3) Inserts and updates on tables will tend to "expand" some data, therefore next step will be to implement Partitioning to isolate some other regions of data blocks AND enf-of-period maintenance tasks in order to keep data compressed.

Well, if you want to follow this route, please share with us on the comments section how it went for your database or what your findings were, we will appreciate hearing (or better said, reading) from You!

Thanks for your time, have a good time...

Subscribe to Oracle Database Dissected by Email



Bookmark this on Delicious

Migration time: Oracle Database Machine/Exadata

Ver este articulo en Español
Guess what I've been doing lately??!! taking vacations? well, that was on September (and that's another post) watching movies? wish I could... none of that, but something more exciting: migrating multi-terabyte datamarts to some Oracle DBMs/Exadatas!!!

My first attempt back in March was Datapump, and it worked fine up-to database sizes around 2Tb using import over the network (DB Link) which is cool, but has the following caveat: cannot disable estimation when using DB Link and therefore much time is spent just measuring how much info Datapump is going to transfer.

However, lately I've been using something we call O2O migration (Oracle-to-Oracle) that is a set of tools and procedures developed by Oracle with SAP database systems in mind, which easily get into the Terabyte league and on top of that critical downtimes, then need to perform super-fast... and it does!!!

On my last migration, took about 36 hours to make a clone of 10Tb datamart ... results may vary according to source hardware config, and things like storage setup and maker or number of cpus factor in; of course on the other side you need to take into account the DBM/Exadata sizing. Summarizing, results may vary according to your hardware and database sizing.

This is an excellent alternative you may take into account, but remember this tool is not included with the database: is sold as a service from Oracle.

Subscribe to Oracle Database Disected by Email



Bookmark this on Delicious