Mémoire système insuffisante dans le pool de ressources "internes"

SQL Server 2008 Serveur Lié et ad-hoc INSERTs en cause rapide de la fuite de mémoire qui provoque finalement le serveur de répondre et se termine avec l'erreur suivante:

Msg 701, Level 17, State 123, Server BRECK-PC\SQLEXPRESS, Line 2
There is insufficient system memory in resource pool 'internal' to run this 
query.

Location:        qxcntxt.cpp:1052
Expression:      cref == 0
SPID:            51
Process ID:      1880

Le serveur n'est toujours pas répondre jusqu'à ce que SQL Server est redémarré.

Logiciel en cours d'utilisation:

Windows Vista Ultimate 64 bits build 6001 SP1
Microsoft SQL Server 2008 (SP1) - 10.0.2734.0 (X64) Sep 11 2009 14:30:58 Copyright (c) de 1988 à 2008 Microsoft Corporation Express Edition with Advanced Services (64-bit) Windows NT 6.0 (Build 6001: Service Pack 1)
SAOLEDB.11 pilote à partir de SQL Anywhere 11.0.1.2276

Réglage max server memory (MO) 2048 n'a pas aidé.

Ajoutant divers -valeurs g (par exemple, -g256;) pour le Démarrage du serveur, les Paramètres n'ont pas d'aide.

À l'aide de la commande DBCC FREESYSTEMCACHE ( 'ALL' ), DBCC FREESESSIONCACHE et DBCC FREEPROCCACHE n'a pas aidé.

L'installation de la Cumnulative package de mise à jour 4 pour SQL Server 2008 Service Pack 1 n'a pas aidé, même s'il contenait un correctif à une fuite de mémoire symptôme impliquant Lié l'utilisation du Serveur.

Séparant les SÉLECTIONNER ... ROW_NUMBER() OVER ... requête à partir de l'INSERT n'a pas aidé. L'expérimentation a montré que le complexe SÉLECTIONNEZ n'est pas la cause de la fuite de mémoire, l'INSERTION a.

Modifiant le code à utiliser ad-hoc "INSERT INTO OPENROWSET" syntaxe au lieu d'un serveur lié n'a pas aidé; le code ci-dessous montre le serveur lié à l'utilisation.

L'sysinternals.com Processus d'Explorer utilitaire montre que l'utilisation de la mémoire a été associée avec sqlserver.exe, pas les Dll utilisées par le SQL Anywhere pilote OLEDB SAOLEDB.11.

Noter que le SQL Anywhere version de serveur lié (proxy tables) fonctionne bien, "pull", 1,9 million de lignes à partir d'un Serveur SQL server 2008 table SQL Anywhere 11 base de données en une seule opération. La logique montré ici est une tentative d'utiliser le serveur lié à la fonctionnalité de "pousser" la lignes; même direction, une syntaxe différente.

Le code qui suit; 4G de RAM est épuisé au bout de trois ou quatre exécutions de l'EXÉCUTER copy_mss_t2:

EXEC sys.sp_configure 
N'show advanced options',  
N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure
N'max server memory (MB)',
N'2048'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sys.sp_configure
N'show advanced options',
N'0'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC master.dbo.sp_MSset_oledb_prop
N'SAOLEDB.11',
N'AllowInProcess',
1
GO
sp_addlinkedserver
@server = 'mem',
@srvproduct = 'SQL Anywhere OLE DB Provider',
@provider = 'SAOLEDB.11',
@datasrc = 'mem_PAVILION2'
GO
EXEC master.dbo.sp_serveroption
@server=N'mem',
@optname=N'rpc',
@optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption
@server=N'mem',
@optname=N'rpc out',
@optvalue=N'true'
GO
sp_addlinkedsrvlogin
@rmtsrvname = 'mem',
@useself = 'false',
@locallogin = NULL,
@rmtuser = 'dba',
@rmtpassword = 'sql'
GO
CREATE PROCEDURE copy_mss_t2
@from_row            BIGINT,
@to_row              BIGINT,
@rows_copied_count   BIGINT OUTPUT
AS
SELECT *
INTO #t
FROM ( SELECT *,
ROW_NUMBER()
OVER ( ORDER BY sample_set_number,
connection_number )
AS t2_row_number
FROM mss_t2 ) AS ordered_mss_t2
WHERE ordered_mss_t2.t2_row_number BETWEEN @from_row AND @to_row;
SELECT @rows_copied_count = COUNT(*)
FROM #t;
INSERT INTO mem..dba.sa_t2
SELECT sampling_id,
sample_set_number,
connection_number,
blocker_owner_table_name,
blocker_lock_type,
blocker_owner_name,
blocker_table_name,
blocker_reason,
blocker_row_identifier,
current_engine_version,
page_size,
ApproximateCPUTime,
BlockedOn,
BytesReceived,
BytesSent,
CacheHits,
CacheRead,
"Commit",
DiskRead,
DiskWrite,
FullCompare,
IndAdd,
IndLookup,
Isolation_level,
LastReqTime,
LastStatement,
LockCount,
LockName,
LockTableOID,
LoginTime,
LogWrite,
Name,
NodeAddress,
Prepares,
PrepStmt,
QueryLowMemoryStrategy,
QueryOptimized,
QueryReused,
ReqCountActive,
ReqCountBlockContention,
ReqCountBlockIO,
ReqCountBlockLock,
ReqCountUnscheduled,
ReqStatus,
ReqTimeActive,
ReqTimeBlockContention,
ReqTimeBlockIO,
ReqTimeBlockLock,
ReqTimeUnscheduled,
ReqType,
RequestsReceived,
Rlbk,
RollbackLogPages,
TempFilePages,
TransactionStartTime,
UncommitOp,
Userid,
previous_ApproximateCPUTime,
interval_ApproximateCPUTime,
previous_Commit,
interval_Commit,
previous_Rlbk,
interval_Rlbk
FROM #t;
GO
DECLARE @rows_copied_count BIGINT
EXECUTE copy_mss_t2 1110001, 1120000, @rows_copied_count OUTPUT
SELECT @rows_copied_count
GO
EXECUTE create_linked_server
GO
DECLARE @rows_copied_count BIGINT
EXECUTE copy_mss_t2 1120001, 1130000, @rows_copied_count OUTPUT
SELECT @rows_copied_count
GO
EXECUTE create_linked_server
GO

Ici est le Serveur SQL de la table source, contenant environ 1G de données de 1,9 million de lignes:

CREATE TABLE mss_t2 (
sampling_id                       BIGINT NOT NULL,
sample_set_number                 BIGINT NOT NULL,
connection_number                 BIGINT NOT NULL,
blocker_owner_table_name          VARCHAR ( 257 ) NULL,
blocker_lock_type                 VARCHAR ( 32 ) NULL,
blocker_owner_name                VARCHAR ( 128 ) NULL,
blocker_table_name                VARCHAR ( 128 ) NULL,
blocker_reason                    TEXT NULL,
blocker_row_identifier            VARCHAR ( 32 ) NULL,
current_engine_version            TEXT NOT NULL,
page_size                         INTEGER NOT NULL,
ApproximateCPUTime                DECIMAL ( 30, 6 ) NULL,
BlockedOn                         BIGINT NULL,
BytesReceived                     BIGINT NULL,
BytesSent                         BIGINT NULL,
CacheHits                         BIGINT NULL,
CacheRead                         BIGINT NULL,
"Commit"                          BIGINT NULL,
DiskRead                          BIGINT NULL,
DiskWrite                         BIGINT NULL,
FullCompare                       BIGINT NULL,
IndAdd                            BIGINT NULL,
IndLookup                         BIGINT NULL,
Isolation_level                   BIGINT NULL,
LastReqTime                       TEXT NOT NULL DEFAULT '1900-01-01',
LastStatement                     TEXT NULL,
LockCount                         BIGINT NULL,
LockName                          BIGINT NULL,
LockTableOID                      BIGINT NULL,
LoginTime                         TEXT NOT NULL DEFAULT '1900-01-01',
LogWrite                          BIGINT NULL,
Name                              VARCHAR ( 128 ) NULL,
NodeAddress                       TEXT NULL,
Prepares                          BIGINT NULL,
PrepStmt                          BIGINT NULL,
QueryLowMemoryStrategy            BIGINT NULL,
QueryOptimized                    BIGINT NULL,
QueryReused                       BIGINT NULL,
ReqCountActive                    BIGINT NULL,
ReqCountBlockContention           BIGINT NULL,
ReqCountBlockIO                   BIGINT NULL,
ReqCountBlockLock                 BIGINT NULL,
ReqCountUnscheduled               BIGINT NULL,
ReqStatus                         TEXT NULL,
ReqTimeActive                     DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockContention            DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockIO                    DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockLock                  DECIMAL ( 30, 6 ) NULL,
ReqTimeUnscheduled                DECIMAL ( 30, 6 ) NULL,
ReqType                           TEXT NULL,
RequestsReceived                  BIGINT NULL,
Rlbk                              BIGINT NULL,
RollbackLogPages                  BIGINT NULL,
TempFilePages                     BIGINT NULL,
TransactionStartTime              TEXT NOT NULL DEFAULT '1900-01-01',
UncommitOp                        BIGINT NULL,
Userid                            VARCHAR ( 128 ) NULL,
previous_ApproximateCPUTime       DECIMAL ( 30, 6 ) NOT NULL DEFAULT 0.0,
interval_ApproximateCPUTime       AS ( COALESCE ( "ApproximateCPUTime", 0 ) - previous_ApproximateCPUTime ),
previous_Commit                   BIGINT NOT NULL DEFAULT 0,
interval_Commit                   AS  ( COALESCE ( "Commit", 0 ) - previous_Commit ),
previous_Rlbk                     BIGINT NOT NULL DEFAULT 0,
interval_Rlbk                     AS  ( COALESCE ( Rlbk, 0 ) - previous_Rlbk ) )

Ici est la cible de la table dans SQL Anywhere 11:

CREATE TABLE sa_t2 (
sampling_id                       BIGINT NOT NULL,
sample_set_number                 BIGINT NOT NULL,
connection_number                 BIGINT NOT NULL,
blocker_owner_table_name          VARCHAR ( 257 ) NULL,
blocker_lock_type                 VARCHAR ( 32 ) NULL,
blocker_owner_name                VARCHAR ( 128 ) NULL,
blocker_table_name                VARCHAR ( 128 ) NULL,
blocker_reason                    TEXT NULL,
blocker_row_identifier            VARCHAR ( 32 ) NULL,
current_engine_version            TEXT NOT NULL,
page_size                         INTEGER NOT NULL,
ApproximateCPUTime                DECIMAL ( 30, 6 ) NULL,
BlockedOn                         BIGINT NULL,
BytesReceived                     BIGINT NULL,
BytesSent                         BIGINT NULL,
CacheHits                         BIGINT NULL,
CacheRead                         BIGINT NULL,
"Commit"                          BIGINT NULL,
DiskRead                          BIGINT NULL,
DiskWrite                         BIGINT NULL,
FullCompare                       BIGINT NULL,
IndAdd                            BIGINT NULL,
IndLookup                         BIGINT NULL,
Isolation_level                   BIGINT NULL,
LastReqTime                       TEXT NOT NULL DEFAULT '1900-01-01',
LastStatement                     TEXT NULL,
LockCount                         BIGINT NULL,
LockName                          BIGINT NULL,
LockTableOID                      BIGINT NULL,
LoginTime                         TEXT NOT NULL DEFAULT '1900-01-01',
LogWrite                          BIGINT NULL,
Name                              VARCHAR ( 128 ) NULL,
NodeAddress                       TEXT NULL,
Prepares                          BIGINT NULL,
PrepStmt                          BIGINT NULL,
QueryLowMemoryStrategy            BIGINT NULL,
QueryOptimized                    BIGINT NULL,
QueryReused                       BIGINT NULL,
ReqCountActive                    BIGINT NULL,
ReqCountBlockContention           BIGINT NULL,
ReqCountBlockIO                   BIGINT NULL,
ReqCountBlockLock                 BIGINT NULL,
ReqCountUnscheduled               BIGINT NULL,
ReqStatus                         TEXT NULL,
ReqTimeActive                     DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockContention            DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockIO                    DECIMAL ( 30, 6 ) NULL,
ReqTimeBlockLock                  DECIMAL ( 30, 6 ) NULL,
ReqTimeUnscheduled                DECIMAL ( 30, 6 ) NULL,
ReqType                           TEXT NULL,
RequestsReceived                  BIGINT NULL,
Rlbk                              BIGINT NULL,
RollbackLogPages                  BIGINT NULL,
TempFilePages                     BIGINT NULL,
TransactionStartTime              TEXT NOT NULL DEFAULT '1900-01-01',
UncommitOp                        BIGINT NULL,
Userid                            VARCHAR ( 128 ) NULL,
previous_ApproximateCPUTime       DECIMAL ( 30, 6 ) NOT NULL DEFAULT 0.0,
interval_ApproximateCPUTime       DECIMAL ( 30, 6 ) NOT NULL COMPUTE ( COALESCE ( "ApproximateCPUTime", 0 ) - previous_ApproximateCPUTime ),
previous_Commit                   BIGINT NOT NULL DEFAULT 0,
interval_Commit                   BIGINT NOT NULL COMPUTE ( COALESCE ( "Commit", 0 ) - previous_Commit ),
previous_Rlbk                     BIGINT NOT NULL DEFAULT 0,
interval_Rlbk                     BIGINT NOT NULL COMPUTE ( COALESCE ( Rlbk, 0 ) - previous_Rlbk ),
PRIMARY KEY ( sample_set_number, connection_number ) );

J'ai ajouté les instructions CREATE TABLE pour les tables source et cible. Poursuite de l'expérimentation indique que la variété des types de données peut être la cause de la fuite de mémoire; par exemple, plusieurs colonnes de TEXTE, 30 chiffres Décimaux, calculé sous forme de colonnes et ainsi de suite. Mes PROFONDES EXCUSES pour quitter le DDL à partir de l'original de l'énoncé du problème... un peu injuste.
Les premières indications sont que le fait d'avoir plusieurs colonnes de TEXTE dans la table source les causes de la mémoire de SQL Server fuite. Le changement de tous, mais une seule colonne de TEXTE VARCHAR semble faire l'affaire. Un test complet est jusqu'à 250 000 lignes avec zéro RAM augmentation; je vais l'attendre à la fin, puis mettre en place un petit reproductible.

InformationsquelleAutor |

8

N'avez-vous pas besoin de vider la table temp #t après chaque itération? c'est à dire ajouter un TRUNCATE TABLE #t à la fin de votre procédure? Je pense que la table temporaire #t existe jusqu'à ce que votre session se termine, pas jusqu'à ce que la procédure stockée se termine. SELECT INTO juste ajoute à l'existant #t, mais ne la remplace pas.

Une autre chose serait d'utiliser une table permanente pas quelque chose stockées dans la base de données tempdb #tables.
- Un excellent site d'observation! FWIW l'espace total requis pour tous les 1,9 million de lignes est d'environ 1G, alors que la fuite de mémoire utilise plusieurs G de RAM après seulement quelques milliers de lignes sont traitées... donc je ne suis pas à croire qu'il n'a rien à voir avec le temp table (qui a été ajouté après de la fuite de mémoire a été remarqué pour la première fois). Cependant, comme je l'ai dit plus tôt, à ce stade, toutes les suggestions sont les bienvenues.
- De toutes les réponses, y compris celui qui a été supprimé, j'aime vôtre le meilleur, donc je vais vous donner la prime.
- Bien sûr, ce n'est pas le réel réponse (voir ma réponse ci-dessous), mais c'est un peu idiot de proposer un bonus, obtenir tous les intéressés à mon problème, puis tirez-le bonus de loin!
- Si quelqu'un veut upvote la question, ce serait apprécié... c'est un vrai bug dans SQL Server 2008, hard reboot. Je pense que le downvote était enfantin, mais c'est juste moi 🙂
- Génial, merci. Je vous souhaite bonne chance dans une!
- La solution de contournement fonctionne correctement. Je suis en train d'écrire un article sur les différentes façons de charger des données dans une base de données en mémoire, et je peux juste préciser au passage que d'une technique ne fonctionne pas pour les chaînes longues. Ou trois techniques: Serveur Lié, OPENROWSET et SSIS... je suis en train de tester les deux derniers pour confirmer. Trois autres techniques de bien fonctionner: BCP avec la TABLE de CHARGEMENT, MobiLink et SQL Anywhere proxy tables.
InformationsquelleAutor

Le problème est à l'aide d'un serveur lié via le SQL Anywhere 11.0.1 fournisseur de SAOLEDB.11 pour insérer des données dans une colonne cible déclarée de plus de VARCHAR ( 8000 ). Ici est simplifié reproductible:

-- Overview: SQL Server 2008 suffers from a fatal memory leak
--    if an attempt is made to use a linked server and the 
--    SAOLEDB.11 provicer to copy data from SQL Server
--    to a SQL Anywhere 11.0.1 table that contains a single column
--    larger than VARCHAR ( 8000 ); i.e, a VARCHAR ( 8000 ) target
--    column is OK but VARCHAR ( 8001 ) is not. The actual string 
--    length is not an issue, nor is the fact that the SQL Server
--    column is declared as TEXT. The memory leak is faster if
--    there is more than one target column larger than VARCHAR ( 8000 ).
--    The server computer freezes and must be rebooted.
-- Msg 701, Level 17, State 123, Server BRECK-PC\SQLEXPRESS, Line 2
-- There is insufficient system memory in resource pool 'internal' to run this
-- query.
-- Location:        qxcntxt.cpp:1052
-- Expression:      cref == 0
-- SPID:            52
-- Process ID:      2044
---------------------------------------------------------
-- SQL ANYWHERE 11 on target computer
---------------------------------------------------------
-- Target:
-- HP Pavilion laptop, 4GHz Pentium 4, 2G RAM
-- Windows XP SP2
-- SQL Anywhere 11.0.1.2276
---------------------------------------------------------
-- Windows commands used to create and start in-memory database
/*
"%SQLANY11%\bin32\dbinit.exe"^
mem.db
"%SQLANY11%\bin32\dbspawn.exe" -f^
"%SQLANY11%\bin32\dbsrv11.exe"^
-im nw^
-o dbsrv11_log.txt^
mem.db 
"%SQLANY11%\bin32\dbisql.com"^
-c "ENG=mem;DBN=mem;UID=dba;PWD=sql;CON=mem-1"
*/
---------------------------------------------------------
-- Create target table with one single "long" column.
BEGIN
DROP TABLE sa_target;
EXCEPTION WHEN OTHERS THEN
END;
CREATE TABLE sa_target (
primary_key      INTEGER NOT NULL PRIMARY KEY,
string_column_1  VARCHAR ( 8001 ) NOT NULL );
---------------------------------------------------------
--- SQL SERVER 2008 on source (server) computer
---------------------------------------------------------
-- Server:
-- Desktop with Intel Core 2 Quad Q9450 2.66Ghz 4G RAM
-- Windows Vista Ultimate 64 bit build 6001 SP1
-- SQL Server 2008 Express 64 Service Pack 1 with cumulative update package 4:
--    Microsoft SQL Server 2008 (SP1) - 10.0.2734.0 (X64)   Sep 11 2009 14:30:58   
--    Copyright (c) 1988-2008 Microsoft Corporation  Express Edition with    
--    Advanced Services (64-bit) on Windows NT 6.0 <X64>    
--    (Build 6001: Service Pack 1) 
-- SAOLEDB.11 driver from SQL Anywhere 11.0.1.2276
---------------------------------------------------------
-- Windows command used to start osql.exe
/*
"c:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe"^
-d main^
-I^
-l 10^
-P j68Fje9#fyu489^
-S BRECK-PC\SQLEXPRESS^
-U sa
*/
---------------------------------------------------------
-- Create database.
USE master
GO
BEGIN TRY
DROP DATABASE main;
END TRY
BEGIN CATCH
END CATCH;
GO
CREATE DATABASE main
ON PRIMARY
( NAME = main_dat,
FILENAME = 'E:\data\main\main.mdf',
SIZE = 2GB,
FILEGROWTH = 200MB )
LOG ON
( NAME = 'main_log',
FILENAME = 'E:\data\main\main.ldf',
SIZE = 2GB,
FILEGROWTH = 200MB )
GO
----------------------------------------------------------------------------
-- Configure SAOLEDB.11 provider.
USE master
go 
-- SAOLEDB.11 provider dlls registered via these Windows commands:
--    regsvr32 dboledb11.dll
--    regsvr32 dboledba11.dll
EXEC master.dbo.sp_MSset_oledb_prop N'SAOLEDB.11', N'AllowInProcess', 1
GO
-- If the following statement produces this message, it probably means 
-- that 'DisallowAdHocAccess' is already set to zero for SAOLEDB.11:
--
-- RegDeleteValue() returned error 2, 'The system cannot find the file specified.'
EXEC master.dbo.sp_MSset_oledb_prop N'SAOLEDB.11', N'DisallowAdHocAccess', 0
GO
----------------------------------------------------------------------------
-- THIS SECTION WAS NOT RUN.
-- Set up for OPENROWSET usage.
-- NOT REQUIRED for required for Linked Server usage.
USE master
GO
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
GO
----------------------------------------------------------------------------
-- Set up Linked Server usage.
USE main
GO
BEGIN TRY
EXEC sp_droplinkedsrvlogin 
@rmtsrvname = 'mem',
@locallogin = NULL  
END TRY
BEGIN CATCH
END CATCH 
GO
BEGIN TRY
EXEC sp_dropserver
@server = 'mem'
END TRY
BEGIN CATCH
END CATCH 
GO
EXEC sp_addlinkedserver
@server = 'mem',
@srvproduct = 'SQL Anywhere OLE DB Provider',
@provider = 'SAOLEDB.11',
@datasrc = 'mem_PAVILION2' 
GO
EXEC master.dbo.sp_serveroption 
@server=N'mem', 
@optname=N'rpc', 
@optvalue=N'true' 
GO
EXEC master.dbo.sp_serveroption 
@server=N'mem', 
@optname=N'rpc out', 
@optvalue=N'true' 
GO
EXEC sp_addlinkedsrvlogin 
@rmtsrvname = 'mem', 
@useself = 'false', 
@locallogin = NULL, 
@rmtuser = 'dba', 
@rmtpassword = 'sql' 
GO
----------------------------------------------------------------------------
-- Create and fill source table with 1 million rows.
USE main
GO
BEGIN TRY
DROP TABLE mss_source; 
END TRY
BEGIN CATCH
END CATCH 
GO
CREATE TABLE mss_source ( 
primary_key      INTEGER NOT NULL PRIMARY KEY,
string_column_1  TEXT NOT NULL )
GO
BEGIN
DECLARE @primary_key INTEGER 
SELECT @primary_key = 1
BEGIN TRANSACTION
WHILE @primary_key <= 1000000 
BEGIN
INSERT mss_source VALUES (
@primary_key,
REPLICATE ( 'Some test data. ', 2 ) )
SELECT @primary_key = @primary_key + 1
END
COMMIT
END
GO
SELECT COUNT(*) FROM mss_source
GO
-- 1000000
---------------------------------------------------------
-- Copy data to target table.
SELECT CURRENT_TIMESTAMP
GO
INSERT INTO mem..dba.sa_target 
SELECT * 
FROM mss_source
GO
SELECT CURRENT_TIMESTAMP
GO
---------------------------------------------------------
-- Test 1 - Code as shown above.
-- FAILED
-- 
-- Started at 2009-10-12 10:06:33.393
-- 
-- A slow server memory leak began immediately.
-- The initial target insert rate was about 2000 rows per second.
-- Server RAM usage reached 3.82 GB, Physical Memory: 95%, Page File 16236M /16288M
-- The server display became frozen.
-- The server became unresponsive to mouse input.
-- The target insert rate dropped below 1000 rows per second, but inserts continued.
-- The copy process reached 937,817 rows inserted on the target.
-- This dialog box appeared on the server: "Your computer is low on memory"
-- Eventually, the process failed, and this message appeared in the osql.exe window:
-- 
-- Msg 701, Level 17, State 123, Server BRECK-PC\SQLEXPRESS, Line 2
-- There is insufficient system memory in resource pool 'internal' to run this
-- query.
-- Location:        qxcntxt.cpp:1052
-- Expression:      cref == 0
-- SPID:            52
-- Process ID:      2044
-- 
-- Failed at 2009-10-12 10:22:21.817
-- The server disk I/O light remained lit without interruption.
-- The server required a hard reboot.
---------------------------------------------------------
-- Test 2 - Code as shown above, except for VARCHAR ( 8000 ).
-- SUCCESSFUL 
BEGIN
DROP TABLE sa_target;
EXCEPTION WHEN OTHERS THEN
END;
CREATE TABLE sa_target (
primary_key      INTEGER NOT NULL PRIMARY KEY,
string_column_1  VARCHAR ( 8000 ) NOT NULL );
-- Started at 2009-10-12 10:41:46.427
-- There was some slight initial growth in RAM usage on the server.
-- Server RAM usage stabilized at 1.40 GB, Physical Memory: 35%, Page File 1560M /8352M
-- The target insert rate remained about 2000 rows per second throughout.
-- Finished OK at 2009-10-12 10:50:52.240
---------------------------------------------------------
-- Test 3 - Repeat Test 2
-- SUCCESSFUL 
-- Started at 2009-10-12 10:53:38.350
-- No further RAM usage growth on the server.
-- Finished OK at 2009-10-12 11:02:10.457

InformationsquelleAutor

0

Vous pourriez essayer de l'exécution de l'insérer dans les lots au lieu de le jeu de données entier à la fois.
- "Vous pouvez essayer de l'exécution de l'insérer dans les lots au lieu de le jeu de données entier à la fois." - c'est exactement ce que fait le code, la copie des lots de seulement 10 000 lignes à la fois: EXÉCUTER copy_mss_t2 1110001, 1120000, ... - c'est exactement pourquoi la sélection complexe a été utilisé, pour rassembler des minuscules lots. J'ai envisagé d'écrire une seule ligne-EXTRAIRE et INSÉRER la boucle, mais la Bidouille Faktor est plutôt de l'extrême... bases de données relationnelles sont censés gérer des ensembles.
- Essayez un petit batch, pas tout le chemin à un. Continuer à réduire la taille des lots jusqu'à ce qu'il fonctionne. Ou sinon essayez de déplacer les dossiers par l'intermédiaire d'un package SSIS au lieu d'un serveur lié.
- Les expériences montrent que la fuite de mémoire n'est pas liée à la taille du lot; en particulier, la fuite de mémoire est un ordre de grandeur plus grand que la quantité de données transférées. Aussi, l'objectif de ce code est à utiliser liés à la fonctionnalité de serveur, pour les besoins d'un article sur le sujet. Merci pour la suggestion à propos de SSIS, je vais lui donner un aller (mais, malheureusement, "Dans SQL Server Express, l'option pour enregistrer le package qui crée l'assistant n'est pas disponible.")
- Je n'aurais pas pris la peine: les réponses sont marqués vers le bas si elles ne résolvent pas le problème, même s'ils ne sont pas mauvais
- SSIS échec beaucoup plus vite, après moins de 3000 lignes de. Une recherche sur Google indique que 0x8007000E signifie probablement mémoire épuisée, et le Gestionnaire des Tâches de soutiens (à partir de 1G à la 4G de RAM utilisé dans quelques secondes). Je soupçonne SSIS est à l'aide de la même logique que Serveur Lié. Erreur 0xc0202009: Tâche de Flux de Données 1: Code d'Erreur SSIS DTS_E_OLEDBERROR. Une erreur OLE DB a eu lieu. Code d'erreur: 0x8007000E.
- Désolé de blesser vos sentiments, ne pas le faire à nouveau!
- Avez-vous tout en bas de cette? J'ai la même erreur, mais je suis de l'extraction de données à partir de Sybase SQL 2008, par le biais du serveur lié. Le serveur SQL donne le même message d'erreur au bout de 15 minutes de l'exécution d'une requête pour extraire des données.
InformationsquelleAutor HLGEM
0

Au lieu d'utiliser des Tables temporaires, pouvez-vous essayer d'utiliser des tableaux de Variables?

par exemple.
```
DECLARE @ResultTable TABLE (TableId INT PRIMARY KEY, ... etc)
INSERT INTO @ResultTable
SELECT TableId, ....
FROM mss_t2 
... etc. ...
```
- La table temporaire a été introduit après la fuite de mémoire a fait sa première apparition... il a été ajouté une solution de contournement tentative. L'expérimentation montre que la fuite ne se produit pas jusqu'à ce que après la temp table est remplie, lorsque l'INSERT de la table de serveur lié commence. CEPENDANT, quelque chose vaut la peine d'essayer, à ce point! Merci!
InformationsquelleAutor
0

J'ai eu un problème similaire, mon code contient de l'utilisation d'un simple #temp tableau dans une boucle, qui en est l'origine et je l'ai remplacé avec une table permanente.

Semble être au travail.

Merci
Naveen

InformationsquelleAutor

Vous devez vous connecter pour publier un commentaire.