트랜잭션 기능이 데이타 손실을 유발하였다는 말씀이신지요?
 구체적으로 사용하신 버젼과 컴파일러의 버젼 커널 버젼을 알려주시고
어떤 종류의 장애를 경험하셨는지 말씀해주시기 바랍니다.
테이블 사이즈나 row 수, 초당 트랜잭션 처리 수도 알고 싶네요.
 왜냐하면 저의 경우 실재로 상당히 많은 트랜잭션 처리를 위해 쓰고 있으니까요.
(초당 150건의 쿼리, 700만건 정도의 row)
그냥 불안정했더라는 경우를 일반화해서 쓰려고 했던 사람들이 자칫 오해를
할 수도 있으니까요.
 그리고 오라클 같은 경우도 백업 & 복구를 위해 RMAN같은 복구 관리자 부터해서
arch log mode 구동등 많은 기능을 제공하고 있기는 하지만 테이타파일 손실등이 일어날 경우 
100% 복구가 되지 않는 경우는 얼마든지 있습니다. 원래 복구라는게 어느 DBMS든 장애 정도에
 따라서 간단하지 않을 수 있습니다. 그래서 백업 전략이 필요한것이구요.
또 안정적인 운영이라는게 그냥 DBMS엔진만 믿고 맡길 수 없는 성질이기도 하구요.
정전이나 하드웨어 Fail도 일어날 수 있고 실수에 의한 손상도 얼마든지
가능한 시나리오니까요. 그냥 오라클로 2주 사용했더니 괜찮더라 정도는
너무 근거가 약합니다. 저도 오라클을 3년 이상 다루봤고 오라클이
굉장히 안정적이긴하지만 역시 장애도 경험해봤기 때문에 이런 말씀을
드리는겁니다. 만약 어떤 알 수 없는 문제로 장애를 경험하였다면
그것의 문제가 어디에 기인하는지 증명할 수 있어야할겁니다.
  적어도 잘못된 테이블 설계와 데이타파일 손상은 별 상관관계가 없어보입니다.
테이블 잘못 설계하면 느려지거나 의도하지 않는 값들이 들어갈 수는
있어도 테이블이 깨지지는 않습니다. 테이블이 깨지는 경우는 갑작스런
정전으로 인해서 미쳐 버퍼 메모리를 데이터를 disk 에 write하지 못했거나
하드웨어적인 오류 혹은 디스크 손상일 경우인데요.
MyISAM type의 경우는 갑작스런 정전등으로 손상이 일어날 수도 있지만
innodb type은 아시겠지만 오라클처럼 transaction log를 남기고
만약 갑작스런 오류로 중단된다면 데이타베이스 기동시 자동으로
Transaction log의 transaction number로 장애시 커밋되지 못한 데이타는
자동으로 롤백시키고 커밋된 데이타는 roll-forward시켜줍니다.
또 flush 자체도 더 안정적으로 하기 위해 double-write 기능이 구현되어서
flush 중에 오류가 나더라도 충분히 복구가 가능하도록 설계가 되어 있더군요.
따라서 디폴트 타입인 MyISAM보다 더 안정적이라고 볼 수 있습니다.
제작자 말로는 오라클의 기능을 많이 채택하였다고 하는군요.
 (참고자료: http://www.innodb.com/ibman.html)   어쨌든 말씀하신 그런 종류의 데이타파일 손상등의
 장애는 상용 DBMS의 경우도 백업이 없다면 난감한 경우를 겪을 수 있습니다.
  MySQL 엔진은 오라클을 오래써온 제가 봐도 상당히
튼튼하고 안정적입니다. MySQL에서 베타버젼이라고 이야기하면 다른 소프트웨어의
파이널 버젼 정도의 안정성을 보여줬습니다.
실재로 NASA같은 경우도 비용 절감목적으로 오라클에서 MySQL로 마이그레이션한
경우도 있구요.
  참고로 오라클의 경우 테스트 목적으로 사용하는것은 라이센스를 구매하지
않아도 됩니다. 오로지 실재 서비스시에만 구매하면 됩니다.
 :
:  저희 업무에 관련하여 속도는 그다지 문제가 되지 않습니다.
:
:  문제는.... 레코드에 문제가 생겼을때 입니다...
:
:  복구가 상당히 까다롭다는 것입니다.
:
:  물론 평소에 백업을 잘해놓고... 어쩌구 저쩌구... 하면 문제가
:
:  없지요...
:
:  사실 근본적인 문제는 테이블 설계를 좀 잘못 했다는 것에 있지요.
:
:  즉... 트랜잭션을 위해서 innodb 를 사용했을때에는 그만큼
:
:  신뢰성 내지는 안전성이 떨어진다는 것입니다.
: 
:  몇달전에 임대 장비로 Oracle 을 사용한적이 있습니다.
:
:  테스트 겸 해서.. 라이센스를 받지 않고(ㅡㅡ 2주일 정도 사용
:
:  했는데... 전혀 문제가 없더군요.
:
:  트랜잭션 때문에 업무적으로 여러가지 효과를 볼 수 있었습니다.
:
:  그것이 기회가 되어 MySQL 의 innodb 를 사용하게 되었지요.
:
:  잘 돌아는 가지만... 문제가 생겼을때.. 상당히 복구가 힘들다는
:
:  것입니다.
:
:  백업이나 다른 문제는 말 그대로 다른 문제로 생각한다면 말이죠...