OLE DB provider "MSDASQL" ..... nicht genügend Arbeitsspeicher

[francesco]

Hallo,

ich habe ein ziemliches Problem mit dem SQL-Server 2005 (wahrscheinlich in Verbindung mit openrowset).

Zuerst mal die Vorgeschichte:
Bei dem Kunden lief der SQL-Server 2005 mit Service Pack (die Vollversion) einige Jahre.

Hard- und Software des Servers: Pentium DualCore 3GHz, 4GB RAM, WinXP, SQL-Server 2005 inkl. SP.

Über das Netz wurde über eine VBA-Applikation auf eine View (mit entsprechend selektierten dynamischen Spalten) der DB zugegriffen, was auch problemlos funktionierte.

Vor zwei Monaten wurde das Motherboard kaputt und der Kunde (IT- und Netzwerk-Bereich des Kunden) wechselte es aus.
Seitdem ist weder über die externe Applikation noch über die Management-Konsole ein Zugriff auf die View möglich - es kommt folgende Fehlermeldung:

OLE DB provider "MSDASQL" for linked server "(null)" returned message "[Microsoft][ODBC Excel Driver] Nicht genügend Arbeitsspeicher.".
Msg 7303, Level 16, State 1, Procedure Qv_Schichten, Line 5
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "(null)".


In der Management-Konsole habe ich dann versucht, auf andere Tabellen und auch systeminterne bestehende Views zuzugreifen - alles kein Problem.
Sobald ich aber auf meine selbst generierten beiden Views zugreife, kommt es zum Fehler.
Probeweise habe ich sie dann über die MMK gelöscht und versucht durch einen neuen Query wieder zu erzeugen - leider Abbruch mit obigem Fehler.

Hier mal ein Auszug aus der ersten Sicht:


USE [WWALMDB]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

-- Sicht für Schichtmodell erzeugen
create view [dbo].[Qv_Schichten]
as
SELECT ID, Aktuell, Modellname, Frueh_Von, Frueh_Bis, Spaet_Von, Spaet_Bis, Nacht_Von, Nacht_Bis, Modellart,
CASE
WHEN ..........................
THEN 'Frueh'

WHEN ..........................
THEN 'Spaet'

WHEN ..........................
THEN 'Nacht'

ELSE NULL
END AS Schicht

FROM OPENROWSET('MSDASQL', 'Driver=Microsoft Excel-Treiber (*.xls);DBQ=C:\Schicht.xls', 'SELECT * FROM [Tabelle1$]') AS derivedtbl_1


Die zweite View (auf die extern zugegriffen werden kann) ist noch komplexer und beinhaltet eine Störtabelle mit integrierter obiger Schichttabelle.

Ich habe auch in der Konfigurationsoberfläche kontrolliert, dass OPENROWSET aktiviert ist und nach Anklicken des Häckchens OLE-Automatisierung (war nie zuvor an) hat plötzlich das Erzeugen der View
einmal geklappt (es waren auch die Spalteninformationen zu sehen), doch ein SELECT auf die VIEW führte wieder zur obigen Fehlermeldung.
Und nach erneutem Löschen der VIEW ließ sie sich auch nicht mehr erzeugen.

Als das alles nichts brachte, habe ich über die Systemsteuerung den MS-SQL-Server komplett de- und reinstalliert, doch leider blieb der Erfolg aus.
Auch das Umkopieren, Löschen und Rückbenennen der Exel-Datei brachte keinen Erfolg.
Habe auch schon einen intensiven Speichertest gemacht - natürlich ohne fehlerhaftes Ergebnis.


Ich habe absolut keine Idee mehr und auch die IT-Spezialisten des Kunden sind ratlos.


Hat irgendjemand aus diesem Forum einen Lösungsansatz?



Besten Dank für die eventuelle Hilfe im Voraus


Franz

[defo]

Also ganz von vorne (aus Hardware/Treibersicht):
1. Ist sichergestellt, dass nur das Motherboard getauscht wurde?
2. Wurde es baugleich getauscht?
3. Wurde im Rahmen des Tausches ggf. erst/einmalig der MS Update Prozess aktiviert/genutzt, um (notwendige) (Hardware-)Treiberaktualisierungen zu erhalten?
4. Sind dabei ggF. andere Softwarekomponenten ebenfalls (versehentlich) aktualisiert worden.

Aus DB Sicht:
1. Ist es tatsächlich so, dass selbst bei direktem Zugriff (Konsole/sql comand line) nur Dein View knallt?
2. Wenn nein, wie weit kannst Du dich technisch Deinem System "nähern", bis es knallt?
3. Wenn ja, ist das Verhalten identisch, wenn Dein View nur gezielt auf einige Records abgefragt wird (Einschränkung Datenmenge/ spezifische Inhalte)
4. Ist es denkbar, dass das gesamte Problemverhatlen nichts mit dem Schaden zu tun hat, sondern mit "neuen" Inhalten.
5. Der Zugriff erfolgt aus VBA>Excel auf MSSQL?
6. Ist sichergestellt, dass die Treiber vorhanden sind und richtig konfiguriert sind (test mit UDL File> Treiber vorhanden, Connection herstellbar)?

[francesco]

Ich beantwortet mal die Fragen:

A) Hardware und Treiber:
1. Ich habe nun erfahren, dass sowohl MB als auch Festplatte getauscht wurden und ein komplettes Acronis-Backup zurück gespielt wurde.
2. Nein
3. Wahrscheinlich ja
4. Wahrscheinlich ja, doch der Gerätemanager ist sauber und die Ereignisanzeige bis auf Ereignis 1524 (beim Herunterfahren) ebenfalls.


B) Datenbank:
1. Ja
2. Bin direkt auf der Managementkonsole vor Ort als Administrator (sa)
3. Kann View nicht mal erzeugen, da es sofort zur Speicherfehlermeldung kommt.
Habe heute eine komplette neue DB mit nur 2 Spalten und 10 Datenzeilen erzeugt. Anschließend zu dieser DB die oben genannte Schichtview generiert.
Zu meinem Erstaunen war alles fehlerfrei, konnte dann die View auch mit SELECT öffnen.
Anschließend probeweise versucht, die Schichtview auch für die real benutzte Alarm-DB zu erzeugen.
Sonderbareweise funktionierte dies (habe aber weder in der Registry noch sonst wo was geändert).
Nachdem ich den Rechner probeweise zwei mal neu gestartet habe, ging wieder kein Zugriff auf die oben beschriebene VIEW - und zwar in keiner der beiden Datenbanken.
Der Zugriff auf sämtliche anderen Views (wo keine OLE DB - Kommandos auftauchen) geht problemlos.
4. Es wurde nichts hinzu installiert und ich habe ja das Problem bei einer neu angelegten Minimalst-DB auch.
5. Das ist das Frontend, ja. Aber der Zugriff auf die View bringt ja schon über die MMK Probleme.
6. Habe es mit einer udl-Datei getestet und war kein Problem

Nachtrag:
Das extrem sonderbare an der ganzen Sache ist ja, dass ich heute genau einmal die View (eigentlich sind es zwei, die zweitere greift auf Daten der ersten zurück) erzeugen und darauf zugreifen konnte
- und zwar unabhängig von der DB.
Danach ging auch nach Löschen und Neuausführen des Queries nichts mehr, auch nicht nach Löschen der Test-DB und erneutem Anlegen - war sozusagen ein nicht reproduzierbarer positiver "Single-Shot".
Auch seltsam ist, dass meist nach dem Ersten Start der Mangementkonsole für eine x-belibige Abfrage (sogar die Test-Tabelle) es 15 bis 20 Sekunden dauert, bis die Ausführung beendet ist.
Anschließend geht es aber blitzschnell (hat wahrscheinlich mit irgendwelchen Temp-Ordnern zu tun?).
Über MSCONFIG habe ich schon alle Programme deaktiviert, die nicht von Microsoft sind und das alles hat trotzdem nichts gebracht.

Gibt es weitere Ratschläge?

Gruß, Franz

[defo]

ach ich seh grad, windows XP! Das funktioniert doch nicht mehr seit April!


Ist der Rechner in die / eine Windows Domäne eingebunden gewesen?
Falls ja, könnte ich mir vorstellen, dass nach neuem Board das Ding nur noch mit einem Bein in der Domäne hängt? Der Server Dienst war lokal? Oder auch Domäne?

Wie auch immer, ich hab das hier gefunden, ein Berechtigungsproblem:
"The problem comes because the Temp folder of the User under which the SQL server service is running isn't accessible under the credentials which the query is running. Try to to set the security of this temp folder with minimal restrictions. The dsn that gets created every time you run an openrowset query then can be recreated without any credentials conflict. This worked for me without any restart requirements."

Wenn es ein Rechte Problem ist, würde es evtl auch erklären, dass es einmal zu Anfang ging. Nämlich wenn noch nicht alle Dienste laufen. Keine Ahnung was ms da alles so treibt, besonders dann auch mit temporären Accounts, wenn DomainController, Servergespeichertes Profil, .. nicht erreichbar ist usw.

Das Zitat ist aus Stackoverflow:
http://stackoverflow.com/questions/1...sql-for-linked
Da steht auch irgendwo, wo der Folder liegen könnte.

[francesco]

Nein, er ist nur lokal in einer Netz-Workgroup.
Das mit dem Temp-Ordner habe ich auch schon gelesen, der war aber komplett leer und ich habe ihn auch freigegeben.

Gruß, Franz

[francesco]

Heute hatte ich neben anderen Tätigkeiten wieder ein paar Stunden Zeit, mich mit dem Server herumzuärgern.
Hierbei fand ich im Eventviewer von Windows einen einigen Monate zurück liegenden Fehler des HD-Controllers mit jeder Menge disk-errors.
Da die aktuelle Software ja ein Diskimage ist, kam mir der Gedanke, dass sämtliche Acronis-Sicherungen fehlerhaft sind.
Daraufhin richtete die IT-Abteilung des Kunden einen neuen Rechner (Win-XP, Dual Core) ein, wo nur Acronis und Mc.Afee standardmäßig installiert sind.

Ich installierte komplett neu den SQL-Server 2005 als Default-Instanz und testete sofort auf der Konsole die OPENROWSET-Funktion mit der im Thread beschriebenen Excel-Schichttabelle.
Pustekuchen - exakt die gleiche Fehlermeldung wie immer (Nicht genügend Arbeitsspeicher, bla bla bla).

Nun versuchte ich, was passiert, wenn ich den gerade verfügbaren SQL-Express Server 2008 als weitere Instanz in einem kompletten anderen Laufwerkspfad installiere.
Nach Deaktivieren des Servers 2005 und Freigeben von OPENROWSET war ich sofort erfolgreich - ich konnte beide Views
(die eine davon war das Einbinden der Excel-Tabelle und die andere eine Verknüpfung von mehreren Datenbanken plus der ersten View) erstellen.

Leider folgte nun eine Fehlermeldung, die ich noch überhaupt nicht kannte, nämlich:
Internal error: An expression services limit has been reached. Please look for potentially complex expressions in your query, and try to simplify them

Na bravo, ich weiß dass meine zweite View ein Riesenmonster ist, aber die hat auf dem SQL-Server 2005 immer funktioniert.
Meine Frage: Besteht da ein Unterschied zwischen der Normal- und der Expressversion?
Was ist die Ursache, dass die ursprünglich vor 4 Jahren installierte Version (die ja eigentlich komplett die gleiche ist, die ich heute installiert habe) reibungslos lief?
Diese sehr komplexe View wird deshalb benötigt, um aus drei von einer anderen Applikation automatisch generierten Datenbanken plus der Schichtview meine Störtabellenview zu erhalten.
Normalerweise umfasst diese immer ca. 50000 bis 100000 Zeilen.
An der Größe kann es nicht liegen, da ich von der externen Applikation eine neue DB-Gruppe mit etwa 50 Zeilen erzeugen ließ und trotzdem kommt der Fehler.

Fazit: Ein kleiner Erfolg und ein schwerer Dämpfer, denn ich kann ja noch immer nicht auf die View zugreifen.



Und hier ein kleiner Ausschnitt aus dem Monster, das 3 von einer externen Anwendung automatisch updatende Tabellen plus die Schichtview enthält:


SELECT TOP 100 PERCENT Z.AlarmID, Z.GekChar, Z.GegChar, Z.Gekommen, Z.Gegangen, Z.Anlage, Z.Alarmgruppe, Z.TagName, Z.Alarmtext, Z.Priority, Schichtart,
Z.Gesamt_Min, CONVERT(DECIMAL(8,1), DATEDIFF(second, Z.Gekommen, Z.Gegangen)/60.0) AS Stoerminuten,
.
.
CASE WHEN DATEDIFF(second, '1900-01-01' ,CAST(CONVERT(CHAR(12),Z.Gekommen,108) AS DATETIME)) BETWEEN
(DATEPART(hour, Frueh_Von)*3600 + DATEPART(mi, Frueh_Von)*60) AND (DATEPART(hour, Frueh_Bis)*3600 + DATEPART(mi, Frueh_Bis)*60)
AND
DATEDIFF(second, '1900-01-01' ,CAST(CONVERT(CHAR(12),Z.Gegangen,108) AS DATETIME)) BETWEEN
(DATEPART(hour, Frueh_Von)*3600 + DATEPART(mi, Frueh_Von)*60) AND (DATEPART(hour, Frueh_Bis)*3600 + DATEPART(mi, Frueh_Bis)*60)
AND Aktuell = 1
THEN CONVERT(DECIMAL(9,1),DATEDIFF(second,Z.Gekommen, Z.Gegangen) /60.0)
.
.
.
FROM(
SELECT * FROM(
SELECT CONVERT(varchar(20),DATEADD(mi, c.AlarmTimeZoneOffset - c.AlarmDaylightAdjustment * 7.5, c.AlarmTime), 113) AS GekChar,

CASE
WHEN c.ReturnTime > '9999-12-12' THEN ' --STEHT NOCH AN--' -- Alarm noch nicht gegangen
WHEN c.ReturnTime = '1900-01-01 00:00:00.000' THEN 'NULL' -- unplausibel, sollte nicht auftreten
ELSE CONVERT(varchar(20),DATEADD(mi, c.ReturnTimeZoneOffset - c.ReturnDaylightAdjustment * 7.5, c.ReturnTime),113)
END AS GegChar,

DATEADD(mi, c.AlarmTimeZoneOffset - c.AlarmDaylightAdjustment * 7.5, c.AlarmTime)
AS Gek,
CASE
WHEN c.ReturnTime = '1900-01-01 00:00:00.000' THEN 'NULL' -- unplausibel, sollte nicht auftreten
ELSE DATEADD(mi, c.ReturnTimeZoneOffset - c.ReturnDaylightAdjustment * 7.5, c.ReturnTime)
END AS Geg,
.
.
.
FROM dbo.AlarmMaster AS m
INNER JOIN dbo.AlarmConsolidated AS c ON m.AlarmId = c.AlarmId
INNER JOIN dbo.Comment ON c.CommentId = dbo.Comment.CommentId,
dbo.Qv_Schichten AS s

WHERE (m.GroupName <> N'$System') AND s.Aktuell=1
) AS X
,dbo.QV_Schichten
WHERE Aktuell = 1
) AS Z
ORDER BY Z.Gekommen DESC


Es wäre mir auch sehr daran gelegen, diese komplexe View einzudämmen, da der externe Zugriff über das Netz und die Visual-Basic-Applikation
bei realer DB-Größe doch immer um die 20 bis 30 Sekunden dauert, bis die dynamische Excel-Tabelle erstellt ist.
Doch wie kann ich das machen?
Würde es etwas bringen, über eine Batch-Datei spätestens alle 10 Minuten anstelle der View eine DB generieren zu lassen?

Über jede Hilfe bin ich sehr dankbar,

Franz

[defo]

Nein, er ist nur lokal in einer Netz-Workgroup.
Das mit dem Temp-Ordner habe ich auch schon gelesen, der war aber komplett leer und ich habe ihn auch freigegeben.

Eine Freigabe ist keine Berechtigung.
Wenn ich das richtig verstanden habe, liegen die Dateien dort nur im Moment der Nutzung oder erst ab dem Moment. Ob sie abgeräumt werden weiß ich nicht.

Zu dem Rest: Vorstellbar, dass Expressversionen limitiert sind, also, sie sind es definitiv, aber ob an der Stelle...

Testweise könnte man den View in mehrere Views zerlegen, also die Subselects in eigene Views packen, sofern das von machbar ist. Vielleicht ist er dann nicht so pingelig.

[francesco]

So, die Kiste rennt wieder.
Doch logisch kam mir das ganze nicht vor, hier der weitere Fortschritt und Abschluss:

1. Gestern funktionierte das mit dem Erzeugen und Öffnen der View über den MS-SQL-Express 2008, aber es gab andere Probleme.
Das gravierendste war, dass die externe Applikation den neuen Server partout nicht annehmen wollte.

2. Also habe ich auch den 2008er wieder komplett deinstalliert und trug mich schon mit dem Gedanken, nun den 2008 Express aufzuspielen und meine riesige View aufzudröseln.
Da aber das Installieren von 2008 3x so lange dauert wie von 2005, habe ich es probehalber mit dem 2005er wieder versucht. Das Ergebnis war abermals der Speicherfehler.
Nun habe ich mal in den Properties an der Speichereinstellungen geschraubt (AWE, Minimum von 0 auf 30 MB, Minimum per Query von 1024 auf 2048 KB) und anschließend den Server neu gestartet.
Urplötzlich funktionierte alles (Erzeugen der beiden Views und Aufruf der zweiten über SELECT).
Probeweise habe ich die Memory-Werte zurückgestellt und den Server neu gestartet, doch noch immer funktionierte alles einwandfrei.
Sicherheitshalber stellte ich jedoch die Memory-Werte wieder hoch.

Einerseits bin ich nun glücklich, dass alles wieder läuft, andererseits war das ganze nicht so richtig reproduzierbar.
Der eigentliche Unterschied zwischen des nun neu aufgesetzten Rechners zum alten ist:

Alt / neu:
---------
Singlecore vs. Dualcore
WinXP SP2 vs. WinXP SP3
Kein McAfee vs. McAfee

Weitere Unetrschiede gibt es nicht, also für mich äußerst rätselhaft, zumal ich ja auch mit einer fast leeren DB (20 Datensätze) gearbeitet habe - wo soll da ein Speicherfehler entstehen?
Außerdem trat das Problem ja schon beim Erzeugen der (einzigen) OPENROWSET-VIEW mit gerade mal 10x3 Excel-Spalten auf.

Kopfschüttelnd schließe ich nun das Thema und bedanke mich für die Ratschläge.

Gruß, Franz