Blockaden durch Unicode/Convert?

[tw_2]

Hallo,

wir haben eine Anwendung in einer ANSI/ODBC und in einer UNICODE/ADO Version. Beide Applicationen greifen gleichzeitig auf die selbe Datenbank zu (MS-SQL Server 2000).

Wir stellen vermehrt fest, das in der Unicode-Version längere Datenbank-Blockaden entstehen. Leider können wir kein Muster erkennen, das bestimmte Tabellen betroffen sind.

Da die meisten Felder aber noch in varchar und nicht in nvarchar deklariert sind, hier meine Vermutung:

Wenn die Unicode-Version in ein Ansi-Feld schreibt, muss der SQL-Server ein Convert durchführen. Kann das Lock-Kritisch sein z.B. in Hinsicht auf Indeces? Außerdem haben wir auch varchar-Primary Keys (nicht nvarchar). Stellt das ein Problem dar?

Bin für jeden Tipp dankbar!

Gruß

TW

[Bernhard Geyer]

Wird hatten mal das problem mit gemischten Zugriff (DB war varchar, Anwendung hat mit nvarchars gearbeitet) das dann die DB ihre Inidzes nicht verwendet hat und Full-Table Scanns durchgeführt hatte. Ich dacht aber das dieser Fehler nur in der 7er-Version des SQL-Servers vorhanden gewesen wäre.

[tw_2]

Danke für die Antwort. Ja, richtig so einen gemischten Betrieb haben wir auch (Unicode Anwendung und DB zum Teil noch varchar und nicht nvarchar).

Hast Du da nähere Infos bzw. Tips wie ich das rausbekommen? Ich kann nur am Wochende nach und nach die Felder auf nvarchar umstellen. Wäre dann blöd, wenn das nicht die Ursache ist ;-)

[Andreas Kosch]

Hallo,

...und in einer UNICODE/ADO Version...

wenn die Ursache für dieses Problem in der SQL Engine liegen würde, müsste sich der Effekt durch Tests mit SQL-Scripten (N'Unicode-Zeichenkette') nachweisen lassen.

Ich gehe eher davon aus, dass die Datensatzsperren von den ADO-Objekten verursacht werden. ADO hat die Eigenheit, bei Bedarf (wenn die Leitung noch von einem anderen Statement belegt ist) im Hintergrund eine 2. Verbindung (andere Datenbanksitzung) zu öffnen anstelle eine Fehlermeldung auszugeben. Die Transaktionsdauer dieser zusätzlichen Verbindung wird dann nicht vom Programm explizit kontrolliert. Über die Leistungsanzeige von Windows kann man auf dem Client-Rechner mitprotokollieren, ob diese ADO-Eigenheit das Problem verursacht.

Alle anderen Zugriffswege (ODBC bzw. ADO.NET) signalisieren sofort ein Problem (solange die Verbindungszeichenfolge nicht abweichend wie im Fall von MARS konfiguriert wird).

[Bernhard Geyer]

Hab nochmal nachgeschaut: War ein Kunde mit einem 2000er-Server. Zugriff erfolgte über JDBC auf Ansi-Tabellen. Nach Umstellen auf nvarchar-Felder war das Performanceproblem gegessen.

[tw_2]

Vielen Dank für die Antworten.

ADO hat die Eigenheit, bei Bedarf (wenn die Leitung noch von einem anderen Statement belegt ist) im Hintergrund eine 2. Verbindung (andere Datenbanksitzung) zu öffnen anstelle eine Fehlermeldung auszugeben.

Das ist interessant. Dann müsste allerdings eine zweite Connection offen sein (neue SPID im Trace) oder?
Haben Sie dafür noch Quellen, wo man das nachlesen kann?

Über die Leistungsanzeige von Windows kann man auf dem Client-Rechner mitprotokollieren, ob diese ADO-Eigenheit das Problem verursacht.

Das verstehe ich leider noch nicht. Könnten Sie das bitte erklären?

@Bernhard:
Ok, Ziel sollte es von uns auch sein, alle Felder auf nvarchar zu stellen. Bin mir aber nicht sicher ob das das Problem ist. Wenn hier Indizes nicht genutzt werden würden, müssten wir in unseren Traces eigentlich auch Langläufer haben oder?

[Andreas Kosch]

Hallo,

Das verstehe ich leider noch nicht. Könnten Sie das bitte erklären?

Bilder sagen hier mehr als tausend Worte - ich habe 2 Abbildungen angehängt. Diese stammen aus dem Jahr 2004 und sind daher etwas "angegraut" ;-)

[tw_2]

Vielen Dank! Das werde ich mir mal anschauen.

Aber dann müssten doch trotzdem zwei SPIDs im Trace des jeweiligen Users sein, oder?