Witam serdecznie!

Potrzebuję pomocy z importem bazy danych do MySQL. Wersja MySQL 5.5.1
W kilku słowach nakreślę istotę problemu:

Program produkcyjny (na serwerze produkcyjnym) używa bazy MySQL-a do przechowywania danych. Jest to baza oparta na INNODB.
Kopię bazy można wykonać poprzez program produkcyjny wybierając odpowiednią opcję z menu programu, do wyboru mam wszystkie tabele, które dowolnie mogę sobie zaznaczać.Na chwilę obecną kopia jest wykonywana bez jednej tabeli(fen - opisana jako zawierająca min: obrazki BLOB +dane analityczne).
Po wykonaniu kopii mogę tą bazę odtworzyć na serwerze testowym - wszystko działa (nawet bez tej tabeli, jak wspomniałem obrazki + dane analityczne).

Celem zabezpieczenia kopii bazy kiedyś został napisany prosty skrypt robiący zrzut całej bazy do plikuxxx.sql - uruchamiany w nocy tak by nie przeszkadzać w ciągu dnia produkcji.

mysql --opt -u xxxx -pxxxx NazwaBazy > d:\Kopiabazy.sql

Okazało się że ten skrypt działą tylko kopia jest przerywana z powodu zbyt małej wartosci --max_allowed_packet , po zmianie na

mysqldump --opt --max_allowed_packet=1G -u xxxx -pxxxx NazwaBazy > d:\Kopiabazy.sql

kopia wykonuje się do końca prawidłowo - na końcu pliku dump: -- Dump completed on ....

Czyli temat exportu został opanowany.

Serwer produkcyjny to świętość - zabawa przenosi się na serwer testowy i tu powstaje problem:

Pełny dump (z tą nieszczęsną tabelą fen) nie zostaje zaimportowany. Wiersz poleceń się wiesza i koniec.

Polecenie importu:

mysqldump --max_allowed_packet=1G -u xxxx -p NazwaBazy < d:\Kopiabazy.sql

Według mnie proces importu zawiesza się DROP tabeli lin(inna tabela zawierająca BLOB)

Dlaczego na tej tabeli?

Podejrzałem moment zawieszenia poprzez MySQL workbench 5.2 CE - widać jak root próbuje coś robić na tabeli lin.

Mało tego - zrobiłem w nocy export z opcją --hex-blob i próbowałem go zaimportować , oczywiście błąd ten sam - wykrzaczył sie na BLOB ie/ach.

Widać to po charakterystycznych znakach np.

\0&\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0%\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0)\0\0

itd

Przeprowadziłem również opcję importu z chracter-set=utf8 i latin1 nic nie pomogło, poniżej

nagłówek z początku exportu:

-- MySQL dump 10.13 Distrib 5.5.10, for Win64 (x86)

-- Host: localhost Database: xxxxxxx

-- Server version 5.5.10-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;
/!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS /;
/!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION /;
/!40101 SET NAMES utf8 /;
/!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE /;
/!40103 SET TIME_ZONE='+00:00' /;
/!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 /;
/!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 /;
/!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' /;
/!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table accbibl

DROP TABLE IF EXISTS accbibl;
/*!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8 /;
CREATE TABLE accbibl (
biblio varchar(16) DEFAULT ,
chassis varchar(16) DEFAULT ,
accessoire varchar(16) DEFAULT '',
numouvrant smallint(6) DEFAULT '0',
ordre int(11) DEFAULT '0',
param double DEFAULT '0',
recno int(11) NOT NULL AUTO_INCREMENT,
KEY recno (recno),
KEY biblio (biblio),
KEY accessoire (accessoire)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/!40101 SET character_set_client = @saved_cs_client */;

Dzięki za przeczytanie tak złożonego problemu, może któryś z użytkowników miał podobny problem/y i podzieli się z odpowiedzią.

A może jakiś szalony pomysł na rozwiązanie tego problemu? Serwer testowy czeka :)