Mai far crashare mysql...

[gandalf.co...@gmail.com]

.. sopratutto se c'è una tabella con 983.606.622.580 record e ben 7 (sette) indici. Mancano solo 100 miliardi di record da controllare e myisamchk sta girando da 2 giorni, a server fermo.

Ma a quanto può arrivare a crescere una tabella myisam ? C'è un limite?

[Giuseppe Lucente]

Il giorno domenica 14 ottobre 2012 02:08:12 UTC+2, gandalf.co...@gmail.com ha scritto:
> .. sopratutto se c'è una tabella con 983.606.622.580

...ma soprattutto, che c@##0 ci sta dentro in quella tabella
per avere sta pletora di record ? ;)

> Ma a quanto può arrivare a crescere una tabella myisam ?
> C'è un limite?

Ad essere sincero non me lo sono mai chiesto.

Comunque:

# There is a limit of 232 (~4.295E+09) rows in a MyISAM table.
# If you build MySQL with the --with-big-tables option, the
# row limitation is increased to (232)2 (1.844E+19) rows.

http://dev.mysql.com/doc/refman/5.1/en/myisam-storage-engine.html

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Mancano solo 100 miliardi di record da controllare e myisamchk sta girando
> da 2 giorni, a server fermo.

Direi che anche oggi hai imparato qualcosa :)

> Ma a quanto può arrivare a crescere una tabella myisam ? C'è un limite?

Limite o non limite, se voglio usare MySQL (e in alcuni casi sono costretto)
una cosa che mi premuro di fare e` NON usare tabelle MyISAM a meno che non
abbia una lupara puntata dietro la schiena ed un forcone posizionato
all'altezza dei testicoli

Enrico

[gandalf.co...@gmail.com]

Il giorno domenica 14 ottobre 2012 12:01:49 UTC+2, Giuseppe Lucente ha scritto:
> ...ma soprattutto, che c@##0 ci sta dentro in quella tabella
> per avere sta pletora di record ? ;)

I log di Bacula.
Sinceramente ho bacula attivo da un paio di anni e mi son sempre dimenticato
di troncare la tabella dei log dopo un po di tempo.

Non appena resuscita il server, metto un bel cron.

> Ad essere sincero non me lo sono mai chiesto.
> Comunque:
> # There is a limit of 232 (~4.295E+09) rows in a MyISAM table.
> # If you build MySQL with the --with-big-tables option, the
> # row limitation is increased to (232)2 (1.844E+19) rows.

Che tradotto significa: un sacco di righe.

[gandalf.co...@gmail.com]

Il giorno domenica 14 ottobre 2012 12:37:11 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Limite o non limite, se voglio usare MySQL (e in alcuni casi sono costretto)
> una cosa che mi premuro di fare e` NON usare tabelle MyISAM a meno che non
> abbia una lupara puntata dietro la schiena ed un forcone posizionato
> all'altezza dei testicoli

Premetto che non conosco benissimo innodb ma una sua cosa che odio è il fatto di non liberare spazio rimuovendo record.
Una tabella del genere, convertita in innodb, diventerebbe spesso centinaia di giga senza possibilità di ridurne la dimensione anche svuotandola.
Tant'è che su Zabbix, ad esempio, ho messo in cron un bel DROP TABLE per rimpicciolire la tabella history, visto che il suo housekeeper nonostante rimuova record ogni giorno, non riesce a liberare spazio. Domani ne valuto la conversione in myisam.

Ma a parte questo, c'è modo di liberare spazio disco cancellando dati da una tabella innodb?

[nameci]

Sembra che gandalf.co...@gmail.com abbia detto :
> Ma a parte questo, c'ￜ modo di liberare spazio disco cancellando dati da una
> tabella innodb?

OPTIMIZE TABLE
ciao

--
************** (.)_(.) *******************
Un amico ￜ uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65

[Sam]

On 14/10/2012 14:20, gandalf.co...@gmail.com wrote:
> Il giorno domenica 14 ottobre 2012 12:01:49 UTC+2, Giuseppe Lucente ha scritto:
>> ...ma soprattutto, che c@##0 ci sta dentro in quella tabella
>> per avere sta pletora di record ? ;)
>
> I log di Bacula.
> Sinceramente ho bacula attivo da un paio di anni e mi son sempre dimenticato
> di troncare la tabella dei log dopo un po di tempo.

Cioè non ti sei mai accorto che ti sono spariti qualche decina di TB di
spazio? Ma cos'hai, dischi a capacità infinita?

[THe_ZiPMaN]

On 10/14/2012 04:18 PM, nameci wrote:
> Sembra che gandalf.co...@gmail.com abbia detto :

>> Ma a parte questo, c'è modo di liberare spazio disco cancellando dati

>> da una tabella innodb?
>
> OPTIMIZE TABLE

No. Questo ottimizza gli indici, ma non libera lo spazio inusato.


--
Flavio Visentin

Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

[nameci]

THe_ZiPMaN ha detto questo domenica :

> On 10/14/2012 04:18 PM, nameci wrote:
>> Sembra che gandalf.co...@gmail.com abbia detto :
>>> Ma a parte questo, c'è modo di liberare spazio disco cancellando dati
>>> da una tabella innodb?
>>
>> OPTIMIZE TABLE

> No. Questo ottimizza gli indici, ma non libera lo spazio inusato.

Dici. Il mio inglese e' tutt'altro che buono ma dal manuale on line
leggo "You can use OPTIMIZE TABLE to reclaim the unused space and to
defragment the data file". Quel "reclaim the unused space" non vuol
dire liberare lo spazio non usato?

--
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,

[THe_ZiPMaN]

On 10/14/2012 05:06 PM, nameci wrote:
> Dici. Il mio inglese e' tutt'altro che buono ma dal manuale on line
> leggo "You can use OPTIMIZE TABLE to reclaim the unused space and to
> defragment the data file". Quel "reclaim the unused space" non vuol dire
> liberare lo spazio non usato?

Certamente non era così fino alla 4.1, magari con la 5 è cambiato
qualcosa. Non ho sottomano un mysql da testare, comunque non mi risulta
che il bug sia chiuso.
http://bugs.mysql.com/bug.php?id=1341

[gandalf.co...@gmail.com]

Il giorno domenica 14 ottobre 2012 16:27:20 UTC+2, Sam ha scritto:
> Cioè non ti sei mai accorto che ti sono spariti qualche decina di TB di
> spazio? Ma cos'hai, dischi a capacità infinita?

No perchè la partizione con MySQL è in comune con quella dove bacula salva i backup e visto ogni giorno lo spazio crolla non ci ho mai dato peso.

ma non è un problema eh, lo faccio finire solo per curiosità, tanto domani tronco la tabella, averla riparata non mi cambierebbe nulla.

Comunque non sono decine di tera, ma "solo" centinaia di giga.

[gandalf.co...@gmail.com]

Il giorno domenica 14 ottobre 2012 17:15:30 UTC+2, THe_ZiPMaN ha scritto:
> Certamente non era così fino alla 4.1, magari con la 5 è cambiato
> qualcosa. Non ho sottomano un mysql da testare, comunque non mi risulta
> che il bug sia chiuso.
> http://bugs.mysql.com/bug.php?id=1341

Nemmeno con la 5 si riesce a far stringere il file.
Lo dico perchè io ho la 5.qualcosa ovunque, molte delle quali Percona, ed innodb cresce solo.

Se qualcuno avesse una soluzione son tutto orecchi.

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Ma a parte questo, c'è modo di liberare spazio disco cancellando dati da
> una tabella innodb?

Usi un datafile per tabella (invece di grossi datafile cumulativi come da
configurazione di default) e vai di OPTIMIZE TABLE

Enrico

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Comunque non sono decine di tera, ma "solo" centinaia di giga.

Ah beh, questo cambia tutto, eh :D

Enrico

[Stefano L.]

Enrico 'Henryx' Bianchi wrote:

> NON usare tabelle MyISAM a
> meno che non abbia una lupara puntata dietro la schiena ed un forcone
> posizionato all'altezza dei testicoli

Tanto per curiosita', a cosa e' dovuto tutto questo astio ?


--
Stefano L.

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 01:30:48 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Usi un datafile per tabella (invece di grossi datafile cumulativi come da
> configurazione di default) e vai di OPTIMIZE TABLE

Uso già un file per tabella, ma l'optimize non stringe.

[Beppe]

On 14/10/2012 23:21, gandalf.co...@gmail.com wrote:

> Se qualcuno avesse una soluzione son tutto orecchi.

Per zabbix (su MySQL con innodb) ho adottato una soluzione di
partitioning, ogni giorno č salvato su un unico file della partizione e
ogni giorno creo le nuove partizioni ed elimino quelle vecchi. Cosě
volente o nolente lo spazio viene liberato.
Una soluzione analoga con qualche adattamento credo possa essere usata
per qualunque tabella con timestamp

[Cristian "sengo" Mammoli]

Suppongo al fatto che MyISAM non è acid compliant e ai lock a livello di
tabella.

--
BOFH excuse #315:

The recent proliferation of Nuclear Testing

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 10:18:43 UTC+2, Beppe ha scritto:
> Per zabbix (su MySQL con innodb) ho adottato una soluzione di

> partitioning, ogni giorno è salvato su un unico file della partizione e
> ogni giorno creo le nuove partizioni ed elimino quelle vecchi. Così

> volente o nolente lo spazio viene liberato.
> Una soluzione analoga con qualche adattamento credo possa essere usata
> per qualunque tabella con timestamp

Buona idea.
comunque, a me pare una clamorosa ca..ata da parte degli sviluppatori di Zabbix non aver previsto che l'housekeeper notturno non avrebbe liberato un singolo byte, visto che di default fanno tabelle innodb (se non ricordo male eh, perchè ci ho smanettato non poco per adattarlo alla mia infrastruttura)

IMHO, dovevano partizionare di default in fase di installazione.

[Beppe]

On 15/10/2012 11:36, gandalf.co...@gmail.com wrote:

> comunque, a me pare una clamorosa ca..ata da parte degli sviluppatori di Zabbix non aver previsto che l'housekeeper notturno non avrebbe liberato un singolo byte, visto che di default fanno tabelle innodb (se non ricordo male eh, perchč ci ho smanettato non poco per adattarlo alla mia infrastruttura)

Mi pare che innodb sia obbligatorio dalla 1.6, prima era possibile
utilizzare anche MyISAM

> IMHO, dovevano partizionare di default in fase di installazione.

Sě in effetti sarebbe stato parecchio "smart" ma se non ricordo male il
partitioning su mysql č stato introdotto dalla 5.5

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 11:48:17 UTC+2, Beppe ha scritto:
> Sì in effetti sarebbe stato parecchio "smart" ma se non ricordo male il
> partitioning su mysql è stato introdotto dalla 5.5

e vabbè, allora in tal caso non usare innodb per una tabella che diventa di dimensioni ciclopiche. Un po come dire: io ti creo la tabella in innodb perchè mi piace di più, ti metto un housekeeper che cancella i dati, ma il file resterà comunque grosso e ti attacchi.

Boh.

[Giovanni Bechis]

Beppe <be...@fakemail.com> wrote:
> S? in effetti sarebbe stato parecchio "smart" ma se non ricordo male il
> partitioning su mysql ? stato introdotto dalla 5.5
>
Il partitioning c'? sicuramente anche nella 5.1

[Giuseppe Lucente]

Il giorno domenica 14 ottobre 2012 14:20:54 UTC+2, gandalf.co...@gmail.com ha scritto:

> I log di Bacula.
> Sinceramente ho bacula attivo da un paio di anni e mi son
> sempre dimenticato di troncare la tabella dei log dopo un
> po di tempo.
>
> Non appena resuscita il server, metto un bel cron.

Buona idea ... non si sa mai, dovesse ri-accadere magari
la procedura si dimostra piu' rapida :P

> Che tradotto significa: un sacco di righe.

Storage limits : 256TB - avoja :)

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 16:54:06 UTC+2, Giuseppe Lucente ha scritto:
> Buona idea ... non si sa mai, dovesse ri-accadere magari
> la procedura si dimostra piu' rapida :P

Si, credo anche io.

> Storage limits : 256TB - avoja :)

Vacca boia.

[Sam]

On 14/10/2012 23:20, gandalf.co...@gmail.com wrote:
> Il giorno domenica 14 ottobre 2012 16:27:20 UTC+2, Sam ha scritto:

> Comunque non sono decine di tera, ma "solo" centinaia di giga.

Umh? Mi sto perdendo qualcosa nei conti? Se il nr. di record che hai
postato è corretto, ipotizzando per assurdo 10 byte per record:

983.606.622.580 * 10 = 983.606.622 * 10 KB = 983.606 * 10 MB = 983 * 10
GB = 9 TB e rotti.

O mysql ha qualche funzionalità per memorizzare i dati in modo compresso?

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 21:27:01 UTC+2, Sam ha scritto:
> Umh? Mi sto perdendo qualcosa nei conti? Se il nr. di record che hai

> postato � corretto, ipotizzando per assurdo 10 byte per record:

E' corretto

> 983.606.622.580 * 10 = 983.606.622 * 10 KB = 983.606 * 10 MB = 983 * 10
> GB = 9 TB e rotti.

A boh, il server ha 12TB in tutto, dopo il truncate della tabella dei log ho rimediato circa 1.2TB (non centinaia di giga come scritto in precedenza)

Qualcosa non torna... Io ho preso il numero di righe dato da myisamchk nel messaggio di errore, forse non è esatto?

> O mysql ha qualche funzionalit� per memorizzare i dati in modo compresso?

Non ne ho idea.

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Uso già un file per tabella, ma l'optimize non stringe.

Mmm... Ricordavo male... Comunque sia, perche` vuoi recuperare spazio?
Cioe`, capisco una situazione estrema come quella da te riportata, ma
pensare di definire una tabella di e.g. 20Gb e poi troncarla nel momento in
cui supera e.g. 20-5Gb direi che sia una buona strategia di allocazione
dello spazio, non foss'altro per il fatto che riduci eventuali lag dovuti al
ridimensionamento del datafile da parte del file system

Enrico
P.S. e` ovvio poi che un drop table + create table risolve sempre, eh :)

[Enrico 'Henryx' Bianchi]

Giovanni Bechis wrote:

> Il partitioning c'? sicuramente anche nella 5.1

Il partitioning lo emuli pure, eh

Enrico

[Rodolfo]

> Si, credo anche io.
>
>> Storage limits : 256TB - avoja :)
>
> Vacca boia.
>

manco in war games

:-)

[gandalf.co...@gmail.com]

Il giorno lunedì 15 ottobre 2012 23:45:47 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Mmm... Ricordavo male... Comunque sia, perche` vuoi recuperare spazio?
> Cioe`, capisco una situazione estrema come quella da te riportata, ma
> pensare di definire una tabella di e.g. 20Gb e poi troncarla nel momento in
> cui supera e.g. 20-5Gb direi che sia una buona strategia di allocazione
> dello spazio, non foss'altro per il fatto che riduci eventuali lag dovuti al
> ridimensionamento del datafile da parte del file system

Forse non ti seguo.
Stai dicendo che è giusto far crescere la tabella all'infinito?
Scusa ma che dischi hai te? Da milioni di terabyte ad espansione dinamica?

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Stai dicendo che è giusto far crescere la tabella all'infinito?

No, sto dicendo di dimensionare la tabella ad una determinata dimensione
(e.g. 20Gb) e di troncarla nel momento in cui raggiunge e/o supera una
determinata dimensione che pero` rientra nel dimensionamento iniziale (e.g.
15Gb, ovvero ti tieni 5Gb come "spazio di manovra")

Enrico

[gandalf.co...@gmail.com]

Il giorno mercoledì 17 ottobre 2012 02:14:38 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> No, sto dicendo di dimensionare la tabella ad una determinata dimensione
> (e.g. 20Gb) e di troncarla nel momento in cui raggiunge e/o supera una
> determinata dimensione che pero` rientra nel dimensionamento iniziale (e.g.
> 15Gb, ovvero ti tieni 5Gb come "spazio di manovra")

Può andar bene nel mio caso, ma in linea generale, reputo sia una grossa limitazione di innodb. Utilizzare una tabella innodb per salvare dei dati 'veri' e non dei log che possono essere rimossi a piacere, sapendo di non poter ma rimpicciolire la tabella senza operazioni invasive (truncate, dump+truncate+restore), è una gigantesca limitazione.

Non riesco a credere che innodb non si restringa cancellando righe.
E' surreale.

[Skull]

On 10/19/12 9:24 AM, gandalf.co...@gmail.com wrote:
> Può andar bene nel mio caso, ma in linea generale, reputo sia una
> grossa limitazione di innodb. Utilizzare una tabella innodb per
> salvare dei dati 'veri' e non dei log che possono essere rimossi a
> piacere, sapendo di non poter ma rimpicciolire la tabella senza
> operazioni invasive (truncate, dump+truncate+restore), è una
> gigantesca limitazione.
>
> Non riesco a credere che innodb non si restringa cancellando righe.
> E' surreale.

Io trovo surreale tutto 'sto thread, sinceramente. Ma tant'è... ;-)
Il problema non è esattamente come lo dipingi.

Prova a leggere questo (commenti e relativi link compresi):

http://jeremy.zawodny.com/blog/archives/010504.html

Ti si aprirà un mondo ;-)

[gandalf.co...@gmail.com]

Il giorno venerdì 19 ottobre 2012 09:46:18 UTC+2, Skull ha scritto:
> Prova a leggere questo (commenti e relativi link compresi):
> http://jeremy.zawodny.com/blog/archives/010504.html
> Ti si aprirà un mondo ;-)

Bisogna comunque andare a smanettare sulle tabelle.
Dover modificare la struttura di una tabella per rimpicciolire le dimensioni
non è una soluzione, ma un workaround.

[Raffaele Tannone]

Il Fri, 19 Oct 2012 00:24:02 -0700, gandalf.corvotempesta ha scritto:

Innanzitutto un saluto al newsgroup visto che questo e' il mio primo
messaggio qui.

> ... reputo sia una grossa

> limitazione di innodb. Utilizzare una tabella innodb per salvare dei
> dati 'veri' e non dei log che possono essere rimossi a piacere, sapendo
> di non poter ma rimpicciolire la tabella senza operazioni invasive
> (truncate, dump+truncate+restore), è una gigantesca limitazione.

Non e' una limitazione di innodb ma di qualsiasi DBMS "tradizionale" a
partire dagli archivi mdb di Access a finire ai datafile di Oracle.
Funzionano tutti cosi'.

> Non riesco a credere che innodb non si restringa cancellando righe. E'
> surreale.

Questa frase mi suona come:
Non riesco a credere che ext3 non si restringe cancellando file. E'
surreale.
In questo ipotetico caso la risposta e' semplice un filesystem non
funziona cosi', nel tuo caso la risposta e' la stessa: un file di storage
fisico di un DBMS non funziona cosi'.

Ciao.

PS La risposta di Enrico e' un approccio corretto.

Tannone Raffaele.

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Non riesco a credere che innodb non si restringa cancellando righe.

Credici, anche perche` non e` l'unico motore di database ad avere questo
comportamento. Riflettici bene, quanto sarebbe oneroso rilasciare lo
spazio occupato dalla tabella ogni volta che la svuoti e richiederlo ogni
volta che la riempi? La strategia migliore in questo caso e` proprio quella
adottata da innodb, sia in modalita` datafile unico (imposti una dimensione
fissa al datafile e lui se ne crea quanti glie ne servono), sia in modalita`
un datafile per tabella (la dimensione viene sempre aumentata e mai
esplicitamente rilasciata). Se proprio vuoi seguire per la tua strada, oltre
al suggerimento che ti ho dato, puoi fare un ALTER TABLE tabella ENGINE =
MyISAM; ALTER TABLE tabella ENGINE = InnoDB; che non fa altro che
ricostruire la tabella ma avente come side effect il fatto di
ridimensionarla

Enrico

[gandalf.co...@gmail.com]

Il giorno sabato 20 ottobre 2012 14:54:38 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Credici, anche perche` non e` l'unico motore di database ad avere questo
> comportamento. Riflettici bene, quanto sarebbe oneroso rilasciare lo
> spazio occupato dalla tabella ogni volta che la svuoti e richiederlo ogni
> volta che la riempi? La strategia migliore in questo caso e` proprio quella
> adottata da innodb, sia in modalita` datafile unico (imposti una dimensione
> fissa al datafile e lui se ne crea quanti glie ne servono), sia in modalita`
> un datafile per tabella (la dimensione viene sempre aumentata e mai
> esplicitamente rilasciata).

Però MyISAM allora risorse ondemand, quindi un qualche sistema ci sarà...
Bada bene, non è un flame, son proprio curioso di capire come mai MyISAM riesce ad 'adattarsi' mentre InnoDB può solo crescere.


Per l'esempio con il filesystem: non credo calzi. Su FS se io creo un file con 10 righe, poi ne cancello 5, il file si restringe.

Anche gli mdb di access non si restringono? Non lo sapevo, non ci ho mai fatto caso.

[gandalf.co...@gmail.com]

Il giorno sabato 20 ottobre 2012 14:54:38 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Se proprio vuoi seguire per la tua strada, oltre
> al suggerimento che ti ho dato, puoi fare un ALTER TABLE tabella ENGINE =
> MyISAM; ALTER TABLE tabella ENGINE = InnoDB; che non fa altro che
> ricostruire la tabella ma avente come side effect il fatto di
> ridimensionarla

Quest'ultima possibile non è praticabile in molti casi. Se hai delle foreign key o le spacca tutte (no buono!) o semplicemente non converte. Non so come si comporti MySQL in questi casi.

[Skull]

On 10/20/12 7:27 PM, gandalf.co...@gmail.com wrote:

> Per� MyISAM allora risorse ondemand, quindi un qualche sistema ci
> sar�...
[...]

> Anche gli mdb di access non si restringono? Non lo sapevo, non ci ho
> mai fatto caso.

Parlare di MyISAM e Access in ambito database � un po' come trattare i
trilobiti in etologia...

[gandalf.co...@gmail.com]

Il giorno sabato 20 ottobre 2012 22:34:01 UTC+2, Skull ha scritto:
> Parlare di MyISAM e Access in ambito database è un po' come trattare i
> trilobiti in etologia...

Ma questo non è un thread sui database, se ci fai caso è un thread senza capo
ne coda, che ho aperto dopo aver visto che diavolo succede facendo crashare un database bacula con moooooooooooooolti log mai rimossi.

Non ha alcuno scopo, non è nulla di più che un insieme di chiacchere da bar.

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Se hai delle foreign key o le spacca tutte (no buono!) o semplicemente
> non converte.

Se ho delle foreign key non uso MyISAM (che, se non ricordo male e quindi
potrei comunque sbagliarmi, non le supporta) :D

Enrico

[gandalf.co...@gmail.com]

Il giorno domenica 21 ottobre 2012 18:44:26 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Se ho delle foreign key non uso MyISAM (che, se non ricordo male e quindi
> potrei comunque sbagliarmi, non le supporta) :D

Appunto: tu dici che per restringere la soluzione è fare una alter table passando da InnoDB a MySQL per poi tornare su InnoDB.

Se hai delle foreinkey (la base di partenza è innodb, quindi puoi averle benissimo) e fai una alter table verso myisam, o il server le spacca tutte, oppure non converte. In ambo i casi, non è una soluzione valida.

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Se hai delle foreinkey (la base di partenza è innodb, quindi puoi averle
> benissimo) e fai una alter table verso myisam, o il server le spacca
> tutte, oppure non converte.

Ovvio, ma io non parlavo di una situazione generica, ma della tua :D
Seriamente, il tuo e` in parte un non problema, in quanto difficilmente
(molto difficilmente) ci sono altri contesti in cui si tende a dare
importanza alla dimensione della tabella su file system (c'e` comunque da
dire che io ragiono spesso e volentieri in ottica datawarehouse)

Enrico

[Enrico 'Henryx' Bianchi]

gandalf.co...@gmail.com wrote:

> Però MyISAM allora risorse ondemand, quindi un qualche sistema ci sarà...

Grazie al cappero, MyISAM e` piu` paragonabile ad un file indicizzato che ad
un sistema di database. Di conseguenza, non mi stupisce il fatto che abbia
un comportamento del genere

Enrico

[gandalf.co...@gmail.com]

Il giorno lunedì 22 ottobre 2012 00:24:56 UTC+2, Enrico 'Henryx' Bianchi ha scritto:
> Ovvio, ma io non parlavo di una situazione generica, ma della tua :D
> Seriamente, il tuo e` in parte un non problema, in quanto difficilmente
> (molto difficilmente) ci sono altri contesti in cui si tende a dare
> importanza alla dimensione della tabella su file system (c'e` comunque da
> dire che io ragiono spesso e volentieri in ottica datawarehouse)

A ok. Ma non prendere come esempio il mio "non problema".
So bene che la mia situazione è perfettamente evitabile, ma il database il
questione non ha alcuna importanza (tant'è che io backuppo tutto tranne quella
tabella), ho fatto finire il myisamchk giusto per curiosità, potevo in
qualunque momento interrompere, cancellare i file, avviare mysql e ricreare al
tabella vuota. Avrei impiegato 1 minuto invece di una settimana.

No, non prendere questo esempio come caso.

[nameci]

Scriveva THe_ZiPMaN domenica, 14/10/2012:
> On 10/14/2012 05:06 PM, nameci wrote:
>> Dici. Il mio inglese e' tutt'altro che buono ma dal manuale on line
>> leggo "You can use OPTIMIZE TABLE to reclaim the unused space and to
>> defragment the data file". Quel "reclaim the unused space" non vuol dire
>> liberare lo spazio non usato?

> Certamente non era così fino alla 4.1, magari con la 5 è cambiato qualcosa.
> Non ho sottomano un mysql da testare, comunque non mi risulta che il bug sia
> chiuso.
> http://bugs.mysql.com/bug.php?id=1341

Ciao,
magari a qualcuno interessa.
Oggi ho avuto modo di verificare quanto detto. Memore di questo vecchio
post ho voluto verificare.
- Dump dei dati antecedenti ad una data
- Delete dei dati antecedenti alla suddetta data
- optimize della tabella

Le dimensioni dei file fisici contenente la tabella si sono ridotte
contestualmente.
OS: Centos 5.8
Mysql: 5.0.1 (mi pare)

--
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65

[gandalf.co...@gmail.com]

Il giorno giovedì 22 novembre 2012 20:13:39 UTC+1, nameci ha scritto:
> Le dimensioni dei file fisici contenente la tabella si sono ridotte
> contestualmente.

Sicuro fosse InnoDB :)

[nameci]

Il 23/11/2012, gandalf.co...@gmail.com ha detto :

Ehm. MyISAM. Sorry ;-(