8 svar · 463 visningar · startad av MickeA.com
Hej,
Jag håller på och migrerar information från en databas till en annan, både MySQL och har gjort såhär:
$mysql1 = mysql_connect("..");
mysql_open_db("db1", $mysql1);
$mysql2 = mysql_connect("..");
mysql_open_db("db2", $mysql2);
När jag sedan ska köra en fråga mot "db1" kör jag:
$result = mysql_query("SELECT foo FROM table", $mysql1);
Då får jag:
db2.table doesn't exist
Hur kan det komma sig?
Jag anger ju till vilken identifier frågan ska ställas till, men ändå blandas dom ihop.
Kör Apache / MySQL på Vista Ultimate om det gör något skillnad.
Några förslag på hur jag löser det här?
Har testat att helt strunta i att öppna anslutningen för $mysql2 och då fungerar allt som det ska.
Problemet är att jag måste ha båda öppna samtidigt för att migreringen ska genomföras.
Har kört samma script förut på min Linuxserver med Debian och det har inte varit några problem. Enda skillnaden då var att jag anslöt mot två olika DBMS, den här gången är det samma databasserver (localhost) fast två olika databaser.
Kan jag göra på något annat sätt?
Tack!
Verkar funkar om jag i frågan anger ...FROM db1.table...
Innebär det att jag inte behöver öppna två separata anslutningar? Hur är det prestandamässigt?
Jag ska nämligen migrera ~100.000 poster (uppåt 45MB) så allt jag kan göra för att förbättra prestandan är bra.
Du behöver titta på flaggan new_link i mysql_connect.
If a second call is made to mysql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned. The new_link parameter modifies this behavior and makes mysql_connect() always open a new link, even if mysql_connect() was called before with the same parameters. In SQL safe mode, this parameter is ignored.
Det går alldeles utmärkt att skriva db1.table och db2.table och använda endast en anslutning, borde inte påverka prestandan åt något håll. Du kanske gör åt marginellt mindre minne.
100.000 rader är ju ingenting, eventuella optimeringar du gör kommer kanske skala nån sekund på den totala exekveringen. Se bara till att unset:a variabler eller öka memory_limit så du inte får slut på minne.
Yes, aha, okej.
Det funkade bra igår, däremot får jag "max_package_size" exeeded (eller något sånt), är det när det är för stor mängd data i output'en?
Nu sitter jag bara och testar lite lokalt, så ska ställa om lite sen i php.ini och köra "på riktigt".
Tack!
/red Ser nu att det är över 300.000 rader som ska migreras, inte 100.000...
Du kan ställa in memory_limit inifrån php med ini_set("memory_limit", "128M") t.ex.
Hur gör du migreringen? Hämta ut från en databas och skriver direkt till den nya? Då borde det räcka med att höja memory_limit en del.
Hur gör du migreringen? Hämta ut från en databas och skriver direkt till den nya? Då borde det räcka med att höja memory_limit en del.
Jag hämtar ut alla poster från den gamla db'n och sen sker lite ändring av viss data för att det ska lira med det nya.
Ska testa höja memory_limit.
Hämtar du ut alla poster direkt och gör bearbetningen sen? Eller gör du bearbetningen för varje post för sig, i t.ex. en while($row = mysql_fetch_assoc($result))? Skulle absolut rekommendera det senare vad gäller minneskrav.
Jo, hämtar ut allt och i while-loopen bearbetas datan. I while-loopen byggs även en insert upp som exekveras när alla poster loopats igenom.
Du bygger alltså en stor insert för alla 300,000 rader? Det förklarar i så fall max_packet_size.
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html
Föreslår att du splittar upp inserten. Du kan utan större problem köra insert varje vända, vid en engångskörning spelar en något längre exekveringstid inte så stor roll. Annars kan du ju köra insert med fasta intervall, typ var hundrade eller tusende rad.