Essbase Dataload using ODI - will my dataload ever finish ??

In older versions of ODI (10.x) while loading data into Essbase, you might find that it takes eternity to load data however big or small it might be in terms of volume. This issue as Oracle claims has been resolved in version 11 but I am not sure and will give it a try when I get an opportunity.

Row by Row insertion : ODI's older version uses an outdated KM for loading data into Essbase, It will load data in bulk from staging area into target until it encounters an erroneous record (You are trying to insert a record which doesnt have a proper member in Essbase associated or data is not numeric). After that it will take each row, validate it and insert in the cube. If you have selected to ignore errors in records while loading  data, you might want to wait till doomsday to finish the dataload.
The best way out is to not ignore erroneous records and cancel the dataload on first error record itself, moreover, it doesn't make sense to ignore records with errors.

Though it remains to be validated, I personally feel that dataload speeds in ODI version 11 have improved as compared to version 10. The reason was that we had migrated from  ODI 10 to 11 while keeping the source, staging and target untouched.

Why is it necessary to start all processes as Administrator ?

If you have tried starting EPM services by double-clicking on the batch scripts in Windows (start.bat, startEssbase.bat etc), you will probably get no error and the black screen will disappear as if nothing happened.
Running the script using a command prompt will give you the same result, it will come out the batch job peacefully, but when you actually check the services if they have started you will be surprised to see that nothing has worked as planned.
The best approach is start the services as 'Run as administrator' or run the cmd prompt in administrator mode.
The installation needs to be done by an administrator or 'Run as administrator' to get the best results.

What about Linux ??
Oracle says that you need to create a new user and it is not recommended to perform installation or start any services by super user. So never sudo...

I have come across this issue once when the services were being started by a super user, but the user who installed it was different, they failed to start.
Going through the logs with help of Oracle revealed that some file attributes (Ownership) are changed on the fly every time services are stopped/started, so this will result in some files not being opened by the service trying to open it.
Solution : If the services were started by some other user and now you need to restore the file access, change the ownership using 'chown' command (recursively) of the 'Oracle' folder

Data Integration ?

Data Integration, simply put, is a way of pulling data from somewhere and putting it somewhere else. I must warn you that its easier said than done.

The most common uses of Data Integration are
1. Building a Central Data Repository : Suppose you have lots of databases spread across various geographies and across different platforms and the business needs to have a central database, which will contain all the data of all geographies in a uniform way.
2. Populating Databases used by Decision Support systems from Transaction Systems : You need to build a data warehouse which will contain information brought in from Transaction systems and then it will be used by BI tools for reporting and analysis
3. Metadata management : Updating Columns, adding new members in a multidimensional database etc can also come under data integration, although there are some disagreements on this.

There are many other cases where data integration tools can be used, the ones posted above are those which you will face most of the times.

Practical Issues of Data Integration
You can find various links regarding this on the net, I will be putting them here again in my words.

Format of Data : The date column in one table might be different from the date column in other. So while integrating both tables (Union) we need to make sure that the date format is uniform in target database.
formatting is perhaps the most common issue faced in integration. It can be as simple as date format or as complex as using particular rules to be written in SQL.

 Mapping : A source data value say INDIA needs to be put as REGION10 in target, Source value US = REGION4 in target, AUSTRALIA=REGION3 and like wise. This will involve using look up tables which will map the source value to a particular target value.

Data Integration time, size and method : The time taken for integration, method of loads (row by row or bulk loads) and the size of data to be loaded will decide the effectiveness of your integration tool.

Scheduling : Data Integration process need to be scheduled properly so that there are no inconsistencies. eg. If you start a data integration process while the source transaction systems are still being updated, the target may or may not have the correct data.

Consistency : The data needs to be consistent across source and target at all times. Changed data capture is a very important aspect in the field of Data Integration.