2017-12-11

Istoria este cinică

Sigur aţi auzit deja de sute de ori platitudinea că „istoria se repetă”. Nici vorbă. Istoria nu se repetă niciodată. Ea, aşa cum bine a spus-o Lucian Boia, merge inexorabil înainte. Mereu înainte, ca şi evoluţia. Nu se opreşte niciodată şi pentru nimic. Cine rămâne în urmă este lăsat în urmă. Istoria este cinică. Nu are sentimente şi nu „ţine” cu nimeni. Ea are propriile repere. Mergi înainte cu ea, sau nu mai mergi deloc. O lecţie elementară pe care mulţi dintre conducătorii noştri vremelnici nu au asimilat-o niciodată. Pentru că ei se cred, atinşi de microbul puterii, mai tari decât istoria. Nu sunt. Nimeni nu este.
A crezut-o Nicolae Ceauşescu în acel decembrie de acum 28 de ani. În demenţa lui autistă a crezut că se poate împotrivi de unul singur cursului istoriei. Asta în contextul în care comunismul (sau, mai precis, ceea ce credea el că reprezintă comunismul) murise deja de ani buni, tot acolo unde se şi născuse cu un secol înainte, şi anume în ghetourile mizere ale muncitorimii. Mai rămăsese din el, cu ani buni înaintea lui 1989, doar o ficţiune de carton menţinută cu forţa. Şi nu americanii i-au dat lovitura de graţie, deşi cărţile de istorie aşa au consemnat. Ei au avut doar răbdare. Au încercuit tumoarea, ca să nu se extindă, şi i-au administrat periodic doze de realitate. A fost arhisuficient. Nu a fost nevoie să-şi desfăşoare avioanele, tancurile şi rachetele, deşi le aveau şi pe acelea pentru orice eventualitate. Au mizat pe istorie. Pe realitate.
republica.ro

2017-12-05

caracterul unei țări este destinul ei.

http://www.tolo.ro/2017/12/05/omagiul-gazetei-sporturilor-la-moartea-regelui-mihai-caracterul-este-destin/

suntem o tara bolnava, insa avem un sistem mai bolnav si neputincios decat bolnavii.

http://robertcadar.ro/izvor-de-motivatie-cancer/

...in general cand boala te prinde in colt esti tentat sa incerci tot felul de chestii, lucru pe care sunt tentat si eu sa-l fac, important e sa tii drumul tau si sa te bazezi pe simturile tale si semnele pe care ti le da organismul.

2017-11-22

mh

"Pe lumea asta nimeni nu e neatins de suferință. Și totuși de atâtea ori alegem să o ignorăm. Cu ochii în telefonul mobil, cu televizorul umplând casa atunci când suntem singuri, refuzăm să ne ascultăm propria voce și fugim de propria tristețe....
Când un om pierde pe cineva pe care îl iubește, când simte că îl va pierde, când îl vede suferind pe patul de spital, îl doare mai mult decât sufletul care se frânge. Pierderea, posibilitatea pierderii, suferința celuilalt dor întotdeauna și fizic. E gheara din piept, nodul din gât, sunt maxilarele amorțite, răceala din mâini și din picioare. E un miros, o lumină, o imagine care generează în cineva atâtea răspunsuri nevăzute, greu de înțeles și greu de suportat. E cearșaful moale de pe patul de spital și marginea tare a scaunului care îți intră în mușchi și îi paralizează. 
Muchia aceea care doare este granița dintre lumea noastră, a celor care putem pleca și a lor, celor forțați să rămână și să îndure. Este linia de la care devenim cu toții mai oameni..."

https://republica.ro/ora-noastra-pe-scaun-si-suferinta-oamenilor-condamnati-sa-isi-duca-viata-pe-el-znu-ma-ridic-de-aici-pana

2017-11-04

Luați loc, vă rog...

„Luați loc, vă rog...” Sunt ultimele cuvinte pe care un părinte le aude înainte ca lumea să înceapă să se prăbușească. Speranțele se năruie, visurile se șterg, zilele sunt înghițite de griji, iar singurele lucruri stabile rămân un munte de suferință și un scaun. Pe acel scaun, aflat lângă patul copilului bolnav de cancer începe să își ducă viața părintele. Pe acel scaun se străduiește să fie puternic, în timp ce se luptă cu o mie de gânduri negre, cu spaima, durerea, epuizarea.


„Dacă părintele nu este puternic, atunci nici copilul nu va avea forța să se lupte cu boala”

„Pe scaun, părinții sunt puternici pentru copiii lor. Când ajung pe coridor, se prăbușesc”, 
 Dacă tu, om sănătos, care nu ai copilul bolnav, înțepenești pe scaunul ăla pentru 30 de minute și încep să te doară toate, imaginează-ți cum e pentru părintele acela care stă zile, săptămâni în șir, cu speranța la pământ, plin de griji și de gânduri”,

https://republica.ro/zdoamne-ia-ma-pe-mine-suferinta-parintilor-care-isi-duc-viata-pe-un-scaun-alaturi-de-copilul-bolnav-si

2017-10-30

c m

http://carymillsap.blogspot.ro/2014/02/how-did-you-learn-so-much-stuff-about.html

2y

Adevărul este că, la lumina trupurilor care au ars în noaptea de 30 octombrie 2015 în clubul Colectiv, am putut vedea cu toții cât de defectă este România, iar asta ne-a umplut de groază, de revoltă, de tristețe şi de dorinţă de schimbare pe mulți dintre noi.
Dar nu pe toţi, prieteni, nu pe toţi, iar asta e cea mai mare problemă.

petreanu.ro

2017-10-16

inflamation

http://m.hotnews.ro/stire/22056176

Dintre cele 10 cauze principale de deces, opt sunt asociate in mod direct unui nivel crescut de inflamatie in organism: bolile de inima, cancerul, bolile respiratorii cronice, accidentul vascular cerebral, boala Alzheimer, diabetul, pneumonia si afectiunile renale. Analiza declansarii bolilor pe fondul unui nivel ridicat de inflamatie este infricosatoare

2017-10-09

ml

https://udarajay.com/applied-machine-learning-the-less-confusing-guide/

mny

"banii n-aduc fericirea. For real. N-o aduc. Si cred ca de-asta mi-a fost destul de usor sa economisesc bani. Ca n-am pe ce sa-i cheltui. Rolul banilor e sa te ajute sa indepartezi/tii la distanta/elimini stressul suplimentar. Dormi mai bine stiind ca ai X in banca. Stiind ca ti-ai platit primu’ mortgage. "

2017-09-22

80+

Ieri am văzut un domn de 80 de ani care nu purta niciun diagnostic, nu lua nicio pastilă. Îl priveam și, cumva, încercam să-mi dau seama care-i era secretul. Am mai mulți pacienți așa, care vin la controale de rutină, sunt 80+, arată ca niște floricele, mintea le e limpede, e o plăcere să-i am în fața mea.
Ce am văzut până acum:
- niciunul nu fumează;
- au făcut exerciții fizice și încă mai fac, fie că vorbim numai despre mersul pe jos, evident subestimat de mulți dintre noi;
- sunt foarte dinamici;
- au hobbiuri, domnul de ieri avea grijă de o grădină și o făcea cu pasiune;
- socializează;
- nu se consumă la toate nimicurile, domnul de ieri nu se gândea mai deloc la pseudofurtuna anunțată;
- mănâncă rațional, toți sunt normoponderali sau puțin peste limită, nimic exagerat, nici vorbă de obezitate;
- nu le au cu alcoolul, câțiva mai beau niște vin sau bere din când în când;
- i-am văzut pe mulți cu cărți la ei;
- starea nu le depinde neapărat de bani, domnul de ieri avea o situație modestă, dar era împăcat cumva cu ideea;
- se bucură de ce au;
- nu se proiectează în furtuni închipuite, trăind în calmul prezent;
- își mențin o relație frumoasă cu medicul și respectă recomandările acestuia;
- au o recunoștință aparte pentru toate lucrurile frumoase care li se întâmplă și cred că așa continuă să le atragă.
Mi-ar plăcea să-i studiez mai mult, să aflu mai multe din poveștile lor. Sunt convins că e și genetica la mijloc, dar la fel de convins sunt că ce am văzut în conduita lor contează enorm.

Vasi Radulescu

2017-09-17

avro parquet

I think the main difference I can describe relates to record oriented vs. column oriented formats. Record oriented formats are what we're all used to -- text files, delimited formats like CSV, TSV. AVRO is slightly cooler than those because it can change schema over time, e.g. adding or removing columns from a record. Other tricks of various formats (especially including compression) involve whether a format can be split -- that is, can you read a block of records from anywhere in the dataset and still know it's schema? But here's more detail on columnar formats like Parquet.
Parquet, and other columnar formats handle a common Hadoop situation very efficiently. It is common to have tables (datasets) having many more columns than you would expect in a well-designed relational database -- a hundred or two hundred columns is not unusual. This is so because we often use Hadoop as a place to denormalize data from relational formats -- yes, you get lots of repeated values and many tables all flattened into a single one. But it becomes much easier to query since all the joins are worked out. There are other advantages such as retaining state-in-time data. So anyway it's common to have a boatload of columns in a table.
Let's say there are 132 columns, and some of them are really long text fields, each different column one following the other and use up maybe 10K per record.
While querying these tables is easy with SQL standpoint, it's common that you'll want to get some range of records based on only a few of those hundred-plus columns. For example, you might want all of the records in February and March for customers with sales > $500.
To do this in a row format the query would need to scan every record of the dataset. Read the first row, parse the record into fields (columns) and get the date and sales columns, include it in your result if it satisfies the condition. Repeat. If you have 10 years (120 months) of history, you're reading every single record just to find 2 of those months. Of course this is a great opportunity to use a partition on year and month, but even so, you're reading and parsing 10K of each record/row for those two months just to find whether the customer's sales are > $500.
In a columnar format, each column (field) of a record is stored with others of its kind, spread all over many different blocks on the disk -- columns for year together, columns for month together, columns for customer employee handbook (or other long text), and all the others that make those records so huge all in their own separate place on the disk, and of course columns for sales together. Well heck, date and months are numbers, and so are sales -- they are just a few bytes. Wouldn't it be great if we only had to read a few bytes for each record to determine which records matched our query? Columnar storage to the rescue!
Even without partitions, scanning the small fields needed to satisfy our query is super-fast -- they are all in order by record, and all the same size, so the disk seeks over much less data checking for included records. No need to read through that employee handbook and other long text fields -- just ignore them. So, by grouping columns with each other, instead of rows, you can almost always scan less data. Win!
But wait, it gets better. If your query only needed to know those values and a few more (let's say 10 of the 132 columns) and didn't care about that employee handbook column, once it had picked the right records to return, it would now only have to go back to the 10 columns it needed to render the results, ignoring the other 122 of the 132 in our dataset. Again, we skip a lot of reading.
(Note: for this reason, columnar formats are a lousy choice when doing straight transformations, for example, if you're joining all of two tables into one big(ger) result set that you're saving as a new table, the sources are going to get scanned completely anyway, so there's not a lot of benefit in read performance, and because columnar formats need to remember more about the where stuff is, they use more memory than a similar row format).
One more benefit of columnar: data is spread around. To get a single record, you can have 132 workers each read (and write) data from/to 132 different places on 132 blocks of data. Yay for parallelization!
And now for the clincher: compression algorithms work much better when it can find repeating patterns. You could compress AABBBBBBCCCCCCCCCCCCCCCC as 2A6B16C but ABCABCBCBCBCCCCCCCCCCCCCC wouldn't get as small (well, actually, in this case it would, but trust me :-) ). So once again, less reading. And writing too.
So we read a lot less data to answer common queries, it's potentially faster to read and write in parallel, and compression tends to work much better.
Columnar is great when your input side is large, and your output is a filtered subset: from big to little is great. Not as beneficial when the input and outputs are about the same.
But in our case, Impala took our old Hive queries that ran in 5, 10, 20 or 30 minutes, and finished most in a few seconds or a minute.
Hope this helps answer at least part of your question!


https://stackoverflow.com/questions/36822224/what-are-the-pros-and-cons-of-parquet-format-compared-to-other-formats

2017-09-15

dieta

http://www.descopera.ro/dnews/11263598-cea-mai-buna-metoda-de-slabit-mai-eficienta-decat-oricare-dieta

"Doi oameni de ştiinţă — Sherry Pagoto de la University of Massachusetts Medical School şi Bradley Appelhans de la Rush University Medical Center din Chicago — lansează un apel pentru încetarea aşa-numitelor „războaie ale dietelor”, pentru că toate sunt la fel de bune (sau rele) în a-i ajuta pe oameni în lupta contra kilogramelor în plus.
În cele din urmă, pacienţii devin confuzi şi ajung să creadă că o dietă este superioară celeilalte, când de fapt schimbările în stilul de viaţă, şi nu dietele, reprezintă singura metodă prin care putem preveni creşterea în greutate şi pericolele asociate, cum ar fi diabetul şi afecţiunile circulatorii."

2017-09-01

Could not verify signing in resource


Doc ID 2289672.1

When attempting to launch JavaClient the following error occurs.

ERROR
Could not verify signing in resource: http://xxxxxxxxx/JavaClient/lib/jagile/saaj.jar

Changes

Installed Java 8 Update 141

Cause

Possible incompatibility with the Java Client code with the security update made in JRE to 1.8.0_141.

WorkAround: Downgrade JRE to version 1.8.0_131 or lower version or Install 1.8.0_144

2017-07-26

nosql world


vasi radulescu

"Am consultat ieri o splendoare de doamnă. Avea 67 de ani și arăta de vreo 45. Cum partea pur medicală se limita la un colesterol mai măricel, am avut timp să discutăm despre literatură, călătorii, filme, prietenii, feluri de mâncare. O priveam și automat mă gândeam la mulți alți pacienți care mai niciodată nu au făcut nimic pentru ei, stând în situații apăsătoare, trăgând pentru alții, strângând pentru zile viitoare așa-zise negre, muncind pe brânci pierzându-și echilibrul psihic, iar apoi, în mod galopant, toate celelalte dându-se peste cap.
Pentru ce strângem bani și lucruri materiale? Pentru ce tot tragem ca să-i mulțumim pe cei din jurul nostru? Intrăm în zone cu nisipuri mișcătoare și nu ne dăm seama cum ne stricăm ca oameni, cum ne scufundăm și, într-un final, pare că am atins un calm, dar este doar nisipul care ne trece de nas și ne servește calmul final.
Trebuie să trăim în special pentru noi. Nu e egoism absurd și rece, e necesitate. Numai iubindu-ne, descoperindu-ne, cultivându-ne putem viețui frumos, apoi, ori de câte ori putem, vom face bine și celor de lângă noi. Viața e un cadou minunat și trebuie să ne bucurăm de el. E al nostru și, cu datele actuale, e irepetabil. La ce bun goane aiurea care ne distrug în loc să ne împlinească?
Doamna mea pacientă îmi povestea despre vizita pe Coasta Amalfi, ultimele cărți citite, renunțarea la cablu tv (îl ține pe domnul televizor numai pentru niște seriale pe Netflix), socializarea cu prietenii, poveștile spuse la un pahar de vin roșu, implicarea încă în niște proiecte interesante (unele pro bono, ajuta niște asociații și asta îi dădea o stare aparte), multiplele călătorii prin Grecia. Am terminat „consultația” și i-am zis că abia aștept să ne revedem.
Trăiți mai ales pentru voi, atingând niveluri care vă permit să faceți bine și-n jurul vostru. Bucurați-vă de lucrurile aparent mărunte care se întâmplă peste tot. Călătoriți. Țineți-vă ocupați cu proiecte frumoase. Nu vă sufocați în obiecte multe care nu vă ajută cu nimic. Nu vă pierdeți sănătatea în maratoane absurde pentru acumulări la fel de absurde.
Viața este, în primul rând, a voastră."

2017-07-05

parquet and hadoop

I think the main difference I can describe relates to record oriented vs. column oriented formats. Record oriented formats are what we're all used to -- text files, delimited formats like CSV, TSV. AVRO is slightly cooler than those because it can change schema over time, e.g. adding or removing columns from a record. Other tricks of various formats (especially including compression) involve whether a format can be split -- that is, can you read a block of records from anywhere in the dataset and still know it's schema? But here's more detail on columnar formats like Parquet.
Parquet, and other columnar formats handle a common Hadoop situation very efficiently. It is common to have tables (datasets) having many more columns than you would expect in a well-designed relational database -- a hundred or two hundred columns is not unusual. This is so because we often use Hadoop as a place to denormalize data from relational formats -- yes, you get lots of repeated values and many tables all flattened into a single one. But it becomes much easier to query since all the joins are worked out. There are other advantages such as retaining state-in-time data. So anyway it's common to have a boatload of columns in a table.
Let's say there are 132 columns, and some of them are really long text fields, each different column one following the other and use up maybe 10K per record.
While querying these tables is easy with SQL standpoint, it's common that you'll want to get some range of records based on only a few of those hundred-plus columns. For example, you might want all of the records in February and March for customers with sales > $500.
To do this in a row format the query would need to scan every record of the dataset. Read the first row, parse the record into fields (columns) and get the date and sales columns, include it in your result if it satisfies the condition. Repeat. If you have 10 years (120 months) of history, you're reading every single record just to find 2 of those months. Of course this is a great opportunity to use a partition on year and month, but even so, you're reading and parsing 10K of each record/row for those two months just to find whether the customer's sales are > $500.
In a columnar format, each column (field) of a record is stored with others of its kind, spread all over many different blocks on the disk -- columns for year together, columns for month together, columns for customer employee handbook (or other long text), and all the others that make those records so huge all in their own separate place on the disk, and of course columns for sales together. Well heck, date and months are numbers, and so are sales -- they are just a few bytes. Wouldn't it be great if we only had to read a few bytes for each record to determine which records matched our query? Columnar storage to the rescue!
Even without partitions, scanning the small fields needed to satisfy our query is super-fast -- they are all in order by record, and all the same size, so the disk seeks over much less data checking for included records. No need to read through that employee handbook and other long text fields -- just ignore them. So, by grouping columns with each other, instead of rows, you can almost always scan less data. Win!
But wait, it gets better. If your query only needed to know those values and a few more (let's say 10 of the 132 columns) and didn't care about that employee handbook column, once it had picked the right records to return, it would now only have to go back to the 10 columns it needed to render the results, ignoring the other 122 of the 132 in our dataset. Again, we skip a lot of reading.
(Note: for this reason, columnar formats are a lousy choice when doing straight transformations, for example, if you're joining all of two tables into one big(ger) result set that you're saving as a new table, the sources are going to get scanned completely anyway, so there's not a lot of benefit in read performance, and because columnar formats need to remember more about the where stuff is, they use more memory than a similar row format).
One more benefit of columnar: data is spread around. To get a single record, you can have 132 workers each read (and write) data from/to 132 different places on 132 blocks of data. Yay for parallelization!
And now for the clincher: compression algorithms work much better when it can find repeating patterns. You could compress AABBBBBBCCCCCCCCCCCCCCCC as 2A6B16C but ABCABCBCBCBCCCCCCCCCCCCCC wouldn't get as small (well, actually, in this case it would, but trust me :-) ). So once again, less reading. And writing too.
So we read a lot less data to answer common queries, it's potentially faster to read and write in parallel, and compression tends to work much better.
Columnar is great when your input side is large, and your output is a filtered subset: from big to little is great. Not as beneficial when the input and outputs are about the same.
But in our case, Impala took our old Hive queries that ran in 5, 10, 20 or 30 minutes, and finished most in a few seconds or a minute.
Hope this helps answer at least part of your question!


2017-06-26

sql developer unable to launch jvm msvrc100.dll

sql developer unable to launch jvm msvrc100.dll

https://stackoverflow.com/questions/31181438/sql-developer-with-jdk-64-bit-cannot-find-jvm

Suppose D:\sqldeveloper is your installation folder:

Create directory bin in
D:\sqldeveloper\jdk\
Copy
msvcr100.dll
from
D:\sqldeveloper\jdk\jre\bin
to
D:\sqldeveloper\jdk\bin

2017-06-07

mapd gpu

http://tech.marksblogg.com/billion-nyc-taxi-rides-nvidia-tesla-mapd.html

"the future of BI reporting is GPU-based. The cards these benchmarks ran on are based on an architecture that's two generations old yet the query times are 55x faster in some cases than I've seen anywhere else - including large clustered CPU solutions."

2017-05-10

ora-0600 [kkpapDIGetNum2]



workaround: 
To work around the problem:
either set "_and_pruning_enabled" = false
or
optimizer_features_enable='10.2.0.5'
You can do this e.g. at session level or via hint to the affected SQL.
e.g.
alter session|system set "_and_pruning_enabled" = false;
or
SELECT /*+ OPT_PARAM('_and_pruning_enabled' 'false') */ ...
To fix the problem upgrade to 12.1 or install patch 10097969 if available.

2017-05-08

18+14

Mi-a luat 18 ani (pe primii 14 nu îi pun)
Să înțeleg că trenul, metroul și trotineta te duc în același loc ca și un Audi;
Să înțeleg că ora este aceeași și dacă ai la mână un Fossil, și dacă ai la mână un Longines, că nu firma ceasului face minutele prețioase, ci cum și cu cine aleg să le petrec;
Să înțeleg că un apartament mare nu face altceva decât să-mi accentueze starea de singurătate dacă nu am cu cine să împart spațiul ăla și dacă nu aud râsete care să-l umple;
Să înțeleg că viața nu se petrece la birou, între patru pereți reci la fel ca oamenii care lucrează acolo, ci afară, în zăpadă, ploaie, vânt sau sub soare. O știam când eram copil, dar am uitat-o odată ce-am devenit adult, lăsându-mă manipulat de societate, de tipare, de oameni la fel de goi precum vorbele pe care le rostesc;
Să înțeleg că nimeni nu te angajează ca să fii liber, că dacă nu lupți pentru visul tău, vei fi doar un sclav pe o plantație;
Să-mi dau seama că mediocrii vor bârfi indiferent de ce ai face și că există răutate gratuită în lume;
Să învăț să nu mai pun la suflet părerile oamenilor „mici”, a celor care n-au fost și nici nu vor ajunge vreodată la nivelul meu;
Să înțeleg că din „bani, femei și băutură” primii sunt doar un mijloc, și nu un scop, ultima are rol de afrodiziac, iar penultimul cuvânt, dacă nu e la singular, ai trăit degeaba;
Să înțeleg că, în viață, tot ce contează e să găsești iubirea și să trăiești fiecare moment ca și cum ar fi ultimul;
Să înțeleg că, atunci când voi avea 80 de ani, nu-mi voi mai aminti mașinile sau ceasurile pe care le-am avut, ci persoanele pe care le-am întâlnit și locurile pe care le-am vizitat;
Să înțeleg că importante sunt acele lucruri ce-ți creează amintiri de neuitat, imagini care îți rămân până la final și, cine știe, poate și dincolo.
Mie mi-a luat 18 ani să înțeleg. Alții nu vor înțelege niciodată. Sper ca unii să înțeleagă mai repede.


actoru cu masca

2017-04-19

unexpected node reboot in RAC

Issue #1: The node rebooted, but the log files do not show any error or cause.

Cause:
If the node reboot is by one of the Oracle processes but log files do not show any error, then the culprit is oprocd, cssdmonitor, and cssdagent processes. This happens when the cluster node was hanging for a while or one or more critical CRS processes cannot get scheduled for CPU. Because those processes run in real time, the underlying issue is likely memory starvation or low free memory and not (literally) CPU starvation. The kernel was swapping pages heavily or was busy scanning memory to identify pages to free up. There could also be an OS scheduling bug at play.

Solution:
1) Set diagwait to 13 if CRS version is 11.1 or lower.
2) If platform is AIX tune AIX VM parameters as suggested in Document 811293.1 (RAC and Oracle Clusterware Best Practices and Starter Kit (AIX)).
3) If the platform is Linux, set up hugepages and set kernel parameter vm.min_free_kbytes to reserve 512MB.  Setting hugepages is probably the single most important thing to do on Linux. Note that memory_target can not be set when using hugepages.
4) If the platform is Linux and kernel is 2.6.18 (i.e. OEL5, Redhat 5, SLES 10) or lower, set kernel parameter swappiness to 100.
Note that there is no need to set kernel parameter swappiness to 100 on Linux Kernel 2.6.32 (i.e. OEL6, Redhat 6, SLES 11) or higher.
5) Disable Transparent HugePages on SLES11, RHEL6, OEL6 and UEK2 Kernels
6) Check if a large amount of memory is allocated to IO buffer cache. Talk to the OS vendor to suggest ways to reduce the amount of IO buffer cache or increase the reclamation rate of memory from IO buffer cache.
7) Increase the amount of memory.

2017-02-08

ORA-17502: ksfdcre on D-NFS

CREATE DATABASE "...."
*
ERROR at line 1:
ORA-01501: CREATE DATABASE failed
ORA-00200: control file could not be created
ORA-00202: control file: '....'
ORA-17502: ksfdcre:.....Failed to create file


Solution:
1) upgrade to oracle 11.2.0.4
2) create first the database on a non- direct nfs filesystem