J'ai actuellement un message d'erreur suivant lors de l'exécution d'un fichier .sql avec environ 26 Mo sur SQL Server 2005:
Msg 701, Level 17, State 123 There is insufficient system memory to run this query.
4 Réponses :
Vous pouvez casser le fichier en plusieurs lots - par exemple. Ajout d'une déclaration Go après chaque mille inserts
E.g. P>
insert db..table( field list ) values ... insert db..table( field list ) values ... go insert db..table( field list ) values ... ... insert db..table( field list ) values ... go
Jusqu'à ce qu'il soit édité, il signifie ajouter une instruction Go après chaque insertion.
J'ai déjà utilisé des déclarations Go pour résoudre le problème, mais je ne veux pas utiliser l'exécution de lots parce que si j'ai eu une erreur, je vais avoir des problèmes de transaction de rentrée ...
Puis insérez du lot dans une autre table par exemple. Dans TEMPDB, puis effectuez la table principale sous forme d'insertion ... Sélectionnez de templdd..x
En outre Sprinkling GO Déclarations de tous ces enregistrements, si vous êtes préoccupé par l'ensemble de la course ou du rouleau, utilisez une transaction comme: avec xact_abort défini sur ON, L'instruction insertion qui échoue annulera la transaction entière.
Vous pouvez ajouter des commandes DBCC entre vos requêtes SQL comme: Cela aidera à libérer la mémoire. En outre, Microsoft publie un correctif pour résoudre ce problème dans SQL Server 2005 (look ici ). Essayez d'installer le Hotfix \ Service Pack.
Cette question semble en fait de venir ici de temps en temps. Mark a le bon (et le plus souvent emploi) réponse, mais je vais essayer d'ajouter ce que je peux pour rendre cela plus clair.
Le message d'erreur est un peu trompeur. SQL Server vous indique qu'il ne dispose pas d'assez de mémoire pour run em> la requête, mais ce qu'il signifie vraiment est qu'il n'a pas assez de mémoire pour parse strong> la requête. p> Quand il vient à en cours d'exécution em> la requête, SQL Server peut utiliser tout ce qu'il veut - giga-octets si nécessaire. Parsing est une autre histoire; le serveur doit construire un arbre d'analyse syntaxique et il y a seulement une quantité très limitée de mémoire disponible pour cela. Je ne l'ai jamais trouvé la limite réelle documenté nulle part, mais pour un lot typique complet de Je Je regrette de vous le dire mais vous ne peut pas em> make SQL Server exécuter ce script exactement comme il est écrit. Pas moyen, pas comment, peu importe ce que les paramètres que vous tweak. Vous, cependant, vous avez un certain nombre d'options de travail autour de lui: p> Plus précisément, vous avez trois options: p> Utilisez Au lieu de générer un script massif pour insérer toutes les lignes, conserver les données dans un fichier de texte (par exemple séparés par des virgules). Puis l'importer en utilisant le utilitaire bcp . Si vous avez besoin que ce soit "scriptable" - à savoir les besoins d'importation pour se produire dans le même script / transaction Si vous voulez vraiment, vraiment Les commentaires précédents suggèrent que vous êtes mal à l'aise avec # 1, bien que cela puisse être juste à cause d'une hypothèse erronée qu'il ne peut se faire en une seule transaction, auquel cas voir réponse Thomas s '. Mais si vous êtes mort sur ensemble une autre façon d'aller, je vous conseille d'aller avec # 2, la création d'un fichier texte et en utilisant INSERT code>, il ne peut pas gérer plus de quelques Mo à la fois. P>
OK code>. Il est utilisé par SSMS et divers autres outils comme séparateur de lots. Au lieu d'un seul arbre d'analyse syntaxique généré pour l'ensemble du texte, les arbres syntaxiques individuels sont générés pour chaque segment du lot séparé par GO code>. C'est ce que la plupart des gens, et il est très simple à faire encore transactionnellement-sûr le script, comme d'autres ont démontré, et je ne vais pas répéter ici. P> li>
CREATE TABLE code> déclaration, puis utilisez BULK INSERT à la place. Bien que BULK INSERT code> est une opération de non-connecté, croyez-le ou non, il peut être placé encore dans un BEGIN TRAN code> / COMMIT TRAN code> bloc. p> li>
INSERT code> pour être une opération journalisée, et ne veulent pas les insertions de se produire dans des lots, vous pouvez utiliser OPENROWSET pour ouvrir un fichier texte, fichier Excel, etc. comme ad-hoc "table" , puis insérez-le dans votre table nouvellement créée. Je suis normalement peu disposé à recommander jamais l'utilisation de OPENROWSET code>, mais comme cela est clairement un script d'administration, ce n'est pas vraiment un problème majeur. P> li>
Ol>
BULK INSERT code>. Un exemple d'un script "sûr" serait: p> BEGIN TRAN
BEGIN TRY
CREATE TABLE MyTable (...)
BULK INSERT MyTable
FROM 'C:\Scripts\Data\MyTableData.txt'
WITH (
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\r\n',
BATCHSIZE = 1000,
MAXERRORS = 1
)
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
END CATCH