I would like to have details on how exadata could ensure availability, security and storage performance. In other words I know that exadata represent both a database(11g2) and a hosting server for that database. How this hosting service and this configuration could be different from other existing configurations

Exadata availability is based primarily on two factors ... RAC and the fact that it is an engineered system so there is less likelihood of issues related to the hardware, configuration, and patching.

Exadata is a hardware platform ... is only marginally related to security. If you publish passwords for root and SYS on Facebook expect bad things to happen.

Storage performance is excellent but without you asking a well defined question the best I can do is recommend you read the docs on Storage Indexing, Hybrid Columnar Compression, and other Exadata specific technologies.

I would recommend Oracle's whitepaper "A Technical Overview of Oracle Exadata Database Machine and Exadata Storage Server" at http://www.oracle.com/technetwork/database/exadata/exadata-technical-whitepaper-134575.pdf It's quite well written and describes how the various Exadata-specific enhancements like storage offloading or I/O resource management can improve performance, scalability, and availability.

1) Availability
Exadata has redundancy for every important component (like Harddisk, Infiniband Switch, Storage Server, DB Server) out of the box built in
You can combine it with (Exadata) Data Guard additionally

2) Security
Not much Exadata Specific here

3) Ease of use
Due to the Engineered System approach - Exadata deployment is much easier than the deployment of a comparable self-cooked system
You will get a reliable and performant system relatively easy and fast.
Administration is NOT easier than administration of other Oracle RAC DBs - it is NOT an appliance

There isn't much Exadata-specific, but the Database Machine consists of a number of servers which have operating systems on them. The configuration and package inventories on these servers are all done with security in mind. The guiding principle is to deliver a system that is "secure by default" which saves a lot of time versus configuring your own system and then iterating through system audits and security scans and then making system configuration adjustments. So, the engineered system benefits extend to security as well as the other areas Uwe pointed out.

The guiding principle is to deliver a system that is "secure by default" which saves a lot of time versus configuring your own system and then
iterating through system audits and security scans and then making system configuration adjustments. So, the engineered system benefits
extend to security as well as the other areas Uwe pointed out.

But when the system come pre-configured ready to be turned on day one, already configured and secured by the Oracle team, isn't this a problem initself? The Oracle team knows more about the configuration than
the customer who has been delivred the exadata machine does?

Another question also came to my mind: when there is a problem within this machine can the local DBA/storage/OS team solve the problem without refering to Oracle? Will this not break a support SLA?

But when the system come pre-configured ready to be turned on day one, already configured and secured by the Oracle team, isn't this a problem initself? The Oracle team knows more about the configuration than
the customer who has been delivred the exadata machine does?

This is the reason there is documentation provided as part of the hand off. Any new system is, by definition, new and you'll know less about it until you start using it and get accustomed to its configuration and setup. This is the reason you shouldn't expect to put your new system into production immediately, but rather after you've tested it and become familiar with it.

Another question also came to my mind: when there is a problem within this machine can the local DBA/storage/OS team solve the problem without refering to Oracle? Will this not break a support SLA?

I'm not sure how you are using the term SLA, but fixing your system yourself doesn't violate any support agreement. Your SLA is your service agreement with your customer and you need to do what you need in order to meet that.

That said, there are some things that you aren't allowed to do (i.e. installing software or making configuration changes on storage cells). But generally speaking, if your system is running normally and has some issue, the issue is more likely related to RAC or RDBMS and changing or fixing things there is within your control to remedy.

On security, there are Exadata specific benefits related to TDE. Both x2-2 and x2-8 get decryption boost by Storage servers due to Intel westmere chips. Please check more details on topic - Hardware encryption support for Oracle Exadata X2.

Again the last step of the onecommand configuration process which should be taking place under the watchful eyes of your in-house DBAs is to expire all the defualt passwords and remove ssh equivalence thereby forcing you to change the keys to the castle as you usher Oracle ACS out the door :)

Well actually now there is some stuff that's Exadata specific with regards to patching from 11.2.3.1.0 onward (see read-me of patch 13741363 for details) basically you have to subscribe to a set of Exadata specific channels on ULN in order to stay up to date with your db server patching. I got a message from the ksplice support folks that ksplice is supported too so I will be trying that out shortly.