[TYPO3-UG Dutch] MySQL: MyISAM of InnoDB

[H. Hahn]

Allemaal heel interessant, maar het beantwoordt nog niet de meest 
essentiële vragen:
a. Hoe kan het dat een of meer tabellen "zomaar ineens" van MyISAM naar 
InnoDB kunnen zijn omgezet?
b. Wat moet ik me voorstellen bij die opmerking over "geen relatie meer 
tussen de tabellen"?

En is die "vervuiling" hetzelfde als de "overhead" die je in PhpMyAdmin 
ngal eens gerapporteerd ziet en die je daar kunt laten verwijderen 
d.m.v. een opdracht "Optimaliseren"?

ries van Twisk schreef:
>
> On Sep 12, 2008, at 8:19 AM, H. Hahn wrote:
>
>> Bedankt.
>> Alleen was het net andersom. Eerst was alles MyISAM, en nu blijken
>> ineens enkele tabellen InnoDB te zijn. Zoals u het schrijft, zou het net
>> andersom zijn, en dat is nu net niet zo. U zegt in feite dat InnoDB
>> "strenger" is dan MyISAM. Dus een vervuilde tabel kan eerder van InnoDB
>> naar MyISAM omgezet worden dan andersom, lijkt me.
>>
>> Die opmerking "geen relatie meer tussen de tabellen" snap ik niet goed.
>> Wat bedoelt u hier met "relatie"? De normale databaserelaties moeten in
>> orde zijn, en dat zijn ze ook, voor zover ik dat in T3 kan nageen mbv.
>> Databaseonderhoud.
>>
>> Maar als InnoDB zoveel betrouwbaarder is (zoals ik uit uw woorden
>> begrijp), waarom gebruikt Typo3 dan standaard MyISAM?
>
> Voordeel van MyISAM: Sneller dan InnoDB
> Nadeel MyISAM: Niet transactional safe, database in MyISAM kan een 
> crash van de OS niet goed doorstaan
>
> Voordeel van InnoDB: support voor MVCC en dus transactional save 
> (ACID) kan een crash van de OS veel beter doorstaan dan MyISAM.
> Nadeel InnoDB: Trager dan MyISAM
>
> Kwa vuile tabellen kan dat altijd in TYPO3 voorkomen omdat TYPO3 geen 
> foreign refrences gebruikt bij database relaties, op zicht niet zo'n 
> heel probleem by typo3 overigens.
>
> Ries
>
>
>>
>>
>> Trouwens, wat moet ik in deze context precies onder "vervuiling" 
>> verstaan?
>>
>> H. Hahn
>>
>> WP Perquin schreef:
>>> Google geeft toch behoorlijk wat antwoorden op je vraag in 
>>> verschillende
>>> postings:
>>> http://www.google.nl/search?hl=nl&q=innodb+typo3&meta=
>>>
>>> De eerste is al raak. Met innodb voorkom je corruptheid van gegevens 
>>> doordat
>>> dubbele writes niet mogen voorkomen. Dat is een issue die wel met 
>>> regelmaat
>>> voorkomt. (Ook ik zie in Zend Platform die melding met regelmaat 
>>> terugkomen:
>>> In bijvoorbeeld de file 
>>> /srv/www/typo3_src-4.1.3/t3lib/class.t3lib_db.php on
>>> line 176 duplicate key) Volgens mij lossen ze dat op door Innodb.
>>>
>>> Ik denk ik jouw geval dat je in enkele tabellen reeds die vervuiling 
>>> hebt
>>> zitten waardoor bij de upgrade automatisch wordt overgeschakeld naar 
>>> MyISAM.
>>> Immers dan is er geen relatie meer tussen de tabellen. Je laatste 
>>> tabel had
>>> die vervuiling niet, waardoor die wel geupgrade kon worden naar INNODB.
>>>
>>> De posts lezende is het beter om INNODB te gebruiken. Daar voorkom je
>>> database vervuiling en instabiliteit mee.
>>>
>>> Wil je het niet hebben:
>>> alter table cache_hash ENGINE = MyISAM;
>>>
>>> Zo'n upgrade uitvoeren op een life database is opzich niet erg mits 
>>> je van
>>> te voren controleert of er geen vervuiling aanwezig is. Gezien je
>>> verschillende database ENGINE's doet de upgrade van TYPO3 dat eerst.
>>>
>>> Mogelijk wanneer je eerst je caches leegt heb je dit probleem niet 
>>> meer en
>>> kan de upgrade wel juist plaatsvinden.
>>>
>>> Succes
>>>
>>> Willem
>>>
>>> -----Oorspronkelijk bericht-----
>>> Van: typo3-ug-dutch-bounces at lists.netfielders.de
>>> [mailto:typo3-ug-dutch-bounces at lists.netfielders.de] Namens H. Hahn
>>> Verzonden: vrijdag 12 september 2008 11:48
>>> Aan: typo3-ug-dutch at lists.netfielders.de
>>> Onderwerp: [TYPO3-UG Dutch] MySQL: MyISAM of InnoDB
>>>
>>> Ik beheer momenteel een stuk of vier websites die op Typo3 -- en dus op
>>> MySQL -- draaien.
>>> Alle vier zijn ze onlangs geüpdate naar Typo3 versie 4.2.1. Dat ging
>>> allemaal prima. De sites draaien ook prima.
>>>
>>> Gisteren wilde ik op één van de sites (de oudste) een toevoeging
>>> aanbrengen waarvoor ik een extra databasetabel nodig had. Met 
>>> PhpMyAdmin
>>> is dat geen enkel probleem.
>>>
>>> Tot mijn verbazing zag ik echter ineens dat een aantal tabellen niet
>>> langer MyISAM zijn, maar InnoDB. Volgens mij was dat eerder niet zo. 
>>> Kan
>>> dat zomaar gewijzigd worden? En zo ja, kan dat vanzelf gebeuren? Ik heb
>>> bij de provider (Xs4all) nagevraagd, maar die weten van niets. Ze
>>> waarschuwen zelfs (m.i. terecht!) voor dergelijke wijzigingen van 
>>> een in
>>> gebruik zijnde database.
>>>
>>> Het betreft de volgende tabellen:
>>>
>>>    cache_hash
>>>    cache_imagesizes
>>>    cache_md5params
>>>    cache_pages
>>>    cache_pagesection
>>>    cache_typo3temp_log
>>>    fe_sessions
>>>    fe_session_data
>>>    sys_log
>>>
>>> Totaal 9 tabellen. Het lijken -- wellicht afgezien van 'fe_sessions' en
>>> 'fe_session_data' -- niet de meest essentiële tabellen te zijn. Merk op
>>> dat van de zeven cache-tabellen 'cache_extensions' er niet bij zit; die
>>> is nog steeds gewoon MyISAM.
>>>
>>> Daar ik onlangs alle vier de websites naar Typo3 4.2.1 heb geüpdate, 
>>> kan
>>> het daar niet aan liggen, want de andere drie zijn gewoon volledig 
>>> MyISAM.
>>>
>>> Heeft iemand enig idee wat hier aan de hand kan zijn?
>>>
>>> H. Hahn
>>> _______________________________________________
>>> TYPO3-UG-dutch mailing list
>>> TYPO3-UG-dutch at lists.netfielders.de
>>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-ug-dutch
>>>
>>>
>>>
>> _______________________________________________
>> TYPO3-UG-dutch mailing list
>> TYPO3-UG-dutch at lists.netfielders.de
>> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-ug-dutch
>
>
>
>             regards, Ries van Twisk
>
>
> ------------------------------------------------------------------------------------------------- 
>
> Ries van Twisk
> tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS 
> WebORB PostgreSQL DB-Architect
> email: ries at vantwisk.nl
> web:   http://www.rvantwisk.nl/
> skype: callto://r.vantwisk
>
>
>
>
>
>
>