1346: Optimize database (Complete) Never Ends [#7316]

[robojock]

I gave it a try my database is 570mb big and its been running now for about 6 hours and still counting

[Ludek]

I gave it a try my database is 570mb big and its been running now for about 6 hours and still counting

And what SQL do you see in DbgView ?

[Friedrich]

Full optimization of ~ 37000 tracks (audio) (180GB) takes about 7-8 minutes here. (Windows XP, Athlon XP 2500+, 1024 MB ram)

[paulmt]

This seems to be the same issue I reported here although perhaps I reported it differently??
Same result though. A full optimization never seems to end, or if I left it long enough i.e. overnight and half the next day it finished, but doing it again after completion doesn't get any faster it goes into another laboriously long hour after hour process.
My database was checked by the SQL check plugin and had no errors. I clean installed MM4 1345 and 1346 and still got the same results. The database was fully optimized by MM3 prior to installing MM4 and took around 3 minutes!

My data base is around 430Mb. While running the MM4 optimization the MM-DB was 436 prior to starting. The optimization ran through once and the MM.DB file went to 408Mb in approx. 3-5 minute but then started to disappear and reappear on and off for another 35 minutes before I got fed up ended the MM4 process to get out of the programme. So the database was compacted but then the optimization went in another sort of process. I watched DBGVIEW and the process was optimizing individual files one after the other and I presume was gong to do this right through the 104k+ tracks ??

Where is the SQL number asked for by Ludek in the log I can't see it anywhere (if thats what he is asking for) or what is he asking for there in the previous post?

When running the full optimization in MM3 the Journal files rebuilds 1-1/2 times and is complete inside 5 minutes.

[Ludek]

I only wanted to say that if you see instant:

Code: Select all

[1376] 3188 DB open SQL: SELECT WebCommercial, WebCopyright, WebFilepage, WebArtist, WebSource, WebRadio, WebPayment, WebPublisher, WebUser, PreviewStartTime, PreviewLength, CacheName, PreviewName, Copyright, Encoder, ISRC, InitialKey, Language, OrigLyricist, ParentalRating,PreGap, PostGap, TotalSamples, GaplessBytes, SignType, SignPart1, SignPart2, SignPart3, SignPart4, ContainerType, StreamCount, StreamInfo FROM Songs WHERE ID = 10 
[1376] 3188 DB lock finished, took 627714.
[1376] 3188 DB exec SQL: INSERT INTO SongsText (rowid,artist,album,albumartist,songtitle,genre,songpath,author,lyricist,conductor,groupdesc,subtitle,lyrics,comment,custom1,custom2,custom3,custom4,custom5,origartist,origtitle,origlyricist,publisher,encoder,copyright,mood,tempo,occasion,quality,involvedpeople) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) 
[1376] 3188 DB lock successful.
[1376] 3188 DB lock finished, took 97554533.

Then it is the full-text search index rebuilding and it is most probably the cause.
Solution would be to add new checkbox [x] Rebuild full-text search index and remove the action from [x] Optimize database (complete)
Reported as: http://www.ventismedia.com/mantis/view.php?id=7315

[Ludek]

BTW: You are right, I found there is a huge performance leak because of rebuilding of full-text search index that takes half an hour on my DB while after optimization it takes only 2 minutes!

Fixed as http://www.ventismedia.com/mantis/view.php?id=7316

Thanks!