Problem mit SQL Script beim kopieren von Tabellen

Hallo Community,

Ich habe eine Frage an euch.

Kurfe Info zur Infrastruktur:

1 x Quellserver ( SQL SERVER 2005)
1 x Zielserver (SQL SERVER 2000)

Ich habe auf dem Quellserver eine Datenbank mit mit mehreren Spalten .
Jetzt möchte ich auf den Zielserver die Tabelle mit der Spalte JOBID von dem Quellserver übertragen.

Das mache ich mit folgendem Script:
Das Script auf dem Quellserver ausgeführt

insert into [Zielserver].test.dbo.Info 
	(
	jobid, appid, jobinitfrom, clientname, idataagent, instance, backupset, subclient, 
	data_sp, backuplevelInt, backuplevel, incrlevel, jobstatusInt, jobstatus, jobfailedreason, startdateunixsec, 
	enddateunixsec, startdate, enddate, durationunixsec, duration, numstreams, numbytesuncomp,
	numbytescomp, numobjects, isAged, isAgedStr 
	)
Select
	jobid, appid, jobinitfrom, clientname, idataagent, instance, backupset, subclient, 
	data_sp, backuplevelInt, backuplevel, incrlevel, jobstatusInt, jobstatus, jobfailedreason, startdateunixsec, 
	enddateunixsec, startdate, enddate, durationunixsec, duration, numstreams, numbytesuncomp,
	numbytescomp, numobjects, isAged, isAgedStr
 
from Datenbank.dbo.info Q

where NOT EXISTS
 (Select 1
from [Zielserver].test.dbo.Info Z
where Z.jobid = Q.jobid)

Das Problem ist jetzt das er auf dem Zielserver an jeden JOBID eine .0 dranhängt z.B (544534.0) (Original: 544534)
Wenn jetzt auf dem Quellserver neue JOBIDS hinzu kommen, soll er bei der nächsten Ausführung nur noch die neu dazugekommenen JOBIDS übertragen.
Wenn nur eine neue JOBID dazugekommen ist, macht er es ohne Probleme. Jetzt habe ich aber 1 Woche nix machen können und habe das Script nochmal ausgeführt,
vorher habe ich folgendendes ausgeführt:

select count (jobid)
from Quellserver			//5033 Stück
select count (jobid)
from Zielserver			//5001 Stück

obwohl nur 32 neue JOBIDS dazugekommen sind, sagt er mir 1034 Arrows effcted

Weiss einer anhand des Scriptes wo mein Fehler liegt.

Der Sinn des Scriptes ist das es 3 Quellserver gibt und alle JOBIDS auf den Zielserver übertragen werden sollen. Auf dem Zielserver sollen alle JOBIDS aber nur einmal vorkommen.

Ich hoffe es kann mir einer helfen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 165797

Url: https://administrator.de/contentid/165797

Ausgedruckt am: 22.11.2024 um 05:11 Uhr

9 Kommentare

Neuester Kommentar

Moin Ruffy1984,

du bist dir aber sicher, dass die Datentypen des Attributes "jobid" in beiden Datenbankinstanzen identisch sind???

Die Datenbankengige scheint an dieser Stelle ja von ganzzahlig in der einen, mit Nachkommastelle in der anderen Tabelle auszugehen.

Was macht denn die Query, wenn du es jeweisl auf Integer CASTest in der "IF NOT EXISTS"-Klausel?

Grüße
Biber

Hey Biber,

Ja .. die Tabelle habe ich mit Attributen 1zu1 als script expotiert. jobist ist : real NULL

Was macht denn die Query, wenn du es jeweisl auf Integer CASTest in der "IF NOT EXISTS"-Klausel?
---> dads verstehe ich jetzt nicht.

Ich habe das ganze natürlich in meiner testumgebung getestet, dort habe ich halt Integer werte benutzt für jobid. Dort habe ich keine Nachkommastelle
Grüße
Ruffy

Moin Ruffy,

ja WTF ist denn die Job-ID auf Real aufgeblasen [edit @ blöder Foren-Big-Brother: auf-ge-pustet.... jezz' besser? f*ckU [/edit]?
Rechnest du denn pessimistisch damit, jemals eine JobId der Form 544534.9182726354 zu bekommen?

Offensichtlich machen die beiden Rechner bei deinen REAL-Zahlen z.B. 544534 irgendwelche Rundungsversuche und sind der Meinung, das vermutlich auf der 87sten nachkommastell irgendetwas unglich 0 stehet (544534.000000....0001).

->Vergleiche also nicht "where Z.jobid = Q.jobid "
-> Sondern : "where Cast(Z.jobid as integer) = cast(Q.jobid as integer)"

[wie auch immer die MSSQL-Syntax dafür lautet - ich hab keinen MSSQL-Server hier.]

Grüße
Biber

Hallo Biber,

ich rechne nicht damit, ein Prgramm schreibt daten in die Datenbank und daher kommen auch die Werte.
das mit dem jobid as integer werde ich testen.

Hallo Biber ,

nochmal ich.

Das mit der .0 dran hängen hat sich erledigt, das ist nur eine View Sache auf derm SQL Server 2000.

Erkennst du irgendwas falsches einem Code , weil er ja mehrere Datensätze überträgt.
Wenn nur 2 neue Jobids dazugekommen sind , sagt er 33 arrows effected.

Grüße Ruffy

Moin Ruffy1984,

dumme Frage - ich war nach dem Aufbau deiner Query stillschweigend davon ausgegangen, das die JOBID auch der primary key, der eindeutig identifizierende Schlüssel der Tabelle ist.

Wenn natürlich erst die Kombination von JOBID und APPID oder JOBID und INSTANCE den Dtensatz identififiert, dann wäre das Verhalten mehr als logisch.

Was ist denn der PK?

P.S.

Erkennst du irgendwas falsches einem Code ...

Ich hab nicht mehr soooo verbissen draufgeschaut, nachdem du erzählt hattest, dass du das JOBID-Feld in der Zieltabelle auf REAL geändert hast.
Da dachte ich: Hey, recht hat er. Datenbanken sind ja nichts hochakademisches oder TÜV-geprüftes.... eine gewisser Fuzzy-Logic-Ähnlichkeitswert reicht auch zum Wiederfinden.

Grüße
Biber

nabend Ruffy,

um Deinem Problem auf die Spur zu kommen, laß doch einfach mal das "insert" weg und führe nur das "select" aus, dann siehst Du ja, welche Daten in die Zieltabelle geschrieben werden sollen. Ich empfehle Dir drei Abfragen:

Select * from Datenbank.dbo.info Q where NOT EXISTS (Select 1 from [Zielserver].test.dbo.Info Z where Z.jobid = Q.jobid)
Select * from [Zielserver].test.dbo.Info Z where NOT EXISTS (Select 1 from Datenbank.dbo.info Q where Z.jobid = Q.jobid)
Select * from Datenbank.dbo.info Q join [Zielserver].test.dbo.Info Z on Z.jobid = Q.jobid

Ausgehend von Deinem ersten Beitrag hätten da wohl 1034, 1002 und 3999 Zeilen zurück kommen müssen.

Du schreibst, Du hast drei Quellserver. Dann nehme ich mal an, daß die anderen zwei Quellserver eben Daten in den Zielserver geschrieben haben, die nicht im dritten Quellserver enthalten sind. Wenn meine Vermutung richtig ist, dann wären das die 1002 Zeilen, die im Zielserver sind, aber nicht im Quellserver.

Wenn meine Vermutung falsch ist, dann kannst Du anhand der Daten aus den drei Abfragen vielleicht erkennen, wo das Problem liegt.

Gruß, Mad Max

Hallo Mad Max,

in die Zieldatenbank, was eine testdatenbank ist wird zur Zeit nur von einem Server Daten rein geschrieben. Ich werde aber deine querys mal testen, Das ist ein Guter Lösungsatz um zu gucken welche Daten übertragen werden.
die Zieldatenbank habe ich folgendermaßen erstellt:
CREATE TABLE [test] (
[jobid] [real] NULL ,
[appid] [int] NOT NULL ,
[jobinitfrom] [varchar] (12) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[clientname] [nvarchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[idataagent] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[instance] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[backupset] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[subclient] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[data_sp] [varchar] (144) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[backuplevelInt] [int] NOT NULL ,
[backuplevel] [varchar] (29) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[incrlevel] [int] NOT NULL ,
[jobstatusInt] [int] NOT NULL ,
[jobstatus] [varchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[jobfailedreason] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[startdateunixsec] [int] NOT NULL ,
[enddateunixsec] [int] NOT NULL ,
[startdate] [datetime] NULL ,
[enddate] [datetime] NULL ,
[durationunixsec] [int] NOT NULL ,
[duration] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[numstreams] [int] NOT NULL ,
[numbytesuncomp] [bigint] NOT NULL ,
[numbytescomp] [bigint] NOT NULL ,
[numobjects] [bigint] NULL ,
[isAged] [int] NOT NULL ,
[isAgedStr] [varchar] (3) NOT NULL
) ON [PRIMARY]
GO

was mir aber gerade auffällt, es existiert kein Primary Key.

Werde später nochmal schreiben, muss jetzt weg.

Grüße