vereinfacht erklärt, erstellt der SQL Server für jedes Query einen Plan (Compiled Execution Plan). Dieser beinhaltet z.B. welche Objekte (Tabellen, Spalten etc) benötigt werden und wie diese miteinander agieren, damit du dein Ergebnis bekommst. Dieser Plan beinhaltet auch ob und welche Indizes genutzt werden sollen und wieviele Datensätze pro Tabelle vorraussichtlich geholt werden müssen.
Das letztere ist nur eine Schätzung auf Grund der Statistiken, welcher der SQL Server bei jeder Tabelle hinterlegt hat. (Die Kardinalität ist hier der entscheidende Faktor)
Auf Grund dieses Plans reserviert der SQL Server auch eine gewisse Menge an RAM, welches explizit dem Query zur Verfügung steht.
Wenn du jetzt aber sagst du hast 30 Parameter, dann vermute ich, dass diese wohl einen großen Einfluss auf den eigentlichen Ablauf des Querys haben.
Z.B. könnte ich mir vorstellen das aus einer TabelleA nur 1 Datensatz benötigt wird und bei einem neuen Lauf mit geänderten Parameter benötigt man vielleicht 10.000 Datensätze.
Mein Tipp ist, wenn das Query schnell genug ist und es wird mit OPTION (RECOMPILE) behoben, dann lass es so.
Wenn nicht, dann solltest du dir Gedanken machen wie du das große Query in kleinere unterteilen kannst.
Oder vielleicht mal die ganze Architektur überdenken, weil vernünftig hört sich das mit 30 Parameter nicht an
Meiner Erfahrung nach, wirst du über die (zu erwartende) Datenmengen nicht an Laufzeiten kommen.
Das klappt oft nur bei simplen Sachen. Wie z.B. einem simplen Insert. Weil das Nadelöhr ist da z.B. I/O und wenn es ein vernünftiges Storagekonzept ist, sollte die Performance relativ stabil sein.
Mach das doch erst einmal über eine Tabelle. Hinterleg den Job mit der maximalen Laufzeit dort.
Die joinst du mit meinen Statement und schon bekommst du alle Jobs mit zu langer Laufzeit.
In einem zweiten Schritt könntest du dann z.B. deine Tabelle, in Betracht der durchschnittlichen Laufzeiten eines vernünftig gewählten Zeitraums, aktualisieren.
Die aktuell laufenden Jobs bekommst du über die sysjobactivity Tabelle.
Z.B. alle laufenden Jobs mit Startzeitpunkt:
SELECT t1.job_id,
t1.name,
t2.start_execution_date
FROM msdb.dbo.sysjobs t1
INNER JOIN msdb.dbo.sysjobactivity t2 ON t2.job_id = t1.job_id
WHERE t2.session_id = (SELECT MAX(session_id) FROM msdb.dbo.syssessions)
AND t2.start_execution_date IS NOT NULL
AND t2.stop_execution_date IS NULL
ORDER BY t2.run_requested_date ASC;
Ich nutze für 'Chunk' Operation immer dieses Skript:
WHILE ( 1 = 1 )
BEGIN
BEGIN TRANSACTION;
DELETE TOP ( 500 )
FROM dbo.table1
WHERE condition IS NULL;
IF @@ROWCOUNT = 0 -- terminating condition;
BEGIN
COMMIT TRANSACTION;
BREAK;
END;
COMMIT TRANSACTION;
END;
Die Anzahl der Rows ist natürlich immer situationsabhängig.
Musst du Millionen von Datensätzen löschen, würde es mit 500 länger dauern, als wenn du z.B. 10000 auf einmal löscht.
Generell solltest aber das machen was dein DBA dir vorgibt. Vorausgesetzt er kennt sich aus ;)
bei Dropbox kannst du am PC auch auswaehlen welche synchronisierte Ordner du nutzen willst.
Nennt sich 'Selective Sync' und befindet sich bei den Erweiterten Eigenschaften.
Brauchst also nicht mehrere Accounts.
Wie das bei Smartphones aussieht weiss ich nicht, nutze Dropbox nur am PC.
Execute the command using any of the Execute methods of the SqlCommand object. Because the command is bound to the notification object, the server recognizes that it must generate a notification, and the queue information will point to the dependencies queue.
wenn man die Screenshots auch so vergleicht, sieht es ja so aus als wird bei Khalid die Platte nicht über AHCI angesprochen werden.
Was dann zumindest die schlechteren Werte erklären würde.
Streaming von Videos ist nicht so simpel wie es aussieht ;)
Du kannst nicht einfach hergehen und byteweise das Zeug über den Äther schicken.
Es gibt dafür Transport Protokolle. Siehe z.B. Wikipedia: MPEG Transport Stream
Am einfachsten ist es wohl per VLC zu streamen.
Ansonsten musst du dir die Transportprotokolle anschauen.
Wenn ich mich nicht ganz irre dürfte ISO/IEC 13818-1:2000 schon mal ein guter Anfang sein.
Ich würde mir eine Komponente holen (z.B. VideoCapX) oder halt VLC dazu nutzen, alles andere artet schnell aus.
Das Problem ist der bescheuerte override von ToString. Naja zumindest für den Entwickler bescheuert, nicht aber fürs Framework.
Die müssten da equals anstatt == verwenden, dann würde man auch von RawFormat den ImageFomat auf anhieb vergleichen können.
Denn bei RawFormat wird ein neuer ImageFormat erstellt anstatt die statischen ImageFormats zurückzugeben.
Folgender Code veranschaulicht das Problem:
Bitmap bitmap = new Bitmap(@"C:\temp\test.jpg");
ImageFormat imageFormat = new ImageFormat(bitmap.RawFormat.Guid);
Console.WriteLine(imageFormat);
Console.WriteLine("Guid the same: " + (imageFormat.Guid == ImageFormat.Jpeg.Guid));
Console.WriteLine("Image types the same: " + (bitmap.RawFormat == ImageFormat.Jpeg));
Console.WriteLine("Image types really not the same?: " + bitmap.RawFormat.Equals(ImageFormat.Jpeg));
Console.WriteLine(ImageFormat.Jpeg.Guid + " | " + ImageFormat.Jpeg);
Console.ReadKey();
ToString ist hier eigentlich nur für die statischen Klassen vernünftig nutzbar.
public static ImageFormat GetImageFormat(Image image)
{
PropertyInfo[] propertyInfos = typeof(ImageFormat).GetProperties(BindingFlags.Public | BindingFlags.Static);
// Have to check via Equals otherwise it cannot be compared
foreach (PropertyInfo info in propertyInfos)
if (info.GetValue(null, null).Equals(image.RawFormat))
return (ImageFormat)info.GetValue(null, null);
// Return MemoryBmp as default
return ImageFormat.MemoryBmp;
}
Hatte bisher keine Probleme damit.
Solltest du performance benötigen kannst du auch noch eine Liste zum vergleichen aufbauen und die ständig abfragen.
ja natürlich kann es passieren das beim konvertieren von Daten Werte verfälscht werden können. Deshalb muss man da ganz genau wissen was rein geht und was hinten raus kommen soll.
Und wie gesagt wenn du bei Parse InvariantCulture angibst, geht er davon aus das dein string der rein geht invariant ist und das müsstest du sicherstellen.
Solltest du nur den Namen der Spalte kennen, kannst du auch SqlDataReader.GetOrdinal nutzen um den Index für SqlDataReader.GetDouble zu bekommen.
naja du solltest dir noch einmal Double.Parse anschauen. Es erwartet einen double als string der bei dir InvariantCulture sein sollte. 2,00 ist aber deutsch und nicht invariant.
Eine Lösung wäre es SqlDataReader.GetDouble zu verwenden, oder halt den richtigen FormatProvider anzugeben.
Btw würde ich für monetäre Variablen decimal als Datentyp verwenden.
Naja also generell geht das so.
Die Frage ist nur ob du mit deinem Account auch drauf kommst.
Das würde meiner Meinung nach definitiv gehen wenn die 2 Domains trusted sind und dein Account auch auf beiden funktioniert.
Solltest du für die andere Domain einen anderen Account (Login oder PW unterschiedlich) haben, dann geht das so ohne weiteres nicht. Dann müsstest du Impersonation nutzen oder per WMI zugreifen (dort könntest du User/PW setzen).
Sollten beide Accounts gleich sein, kann es sein das es geht. Ich weiss nicht inwiefern OpenRemoteBaseKey die Domain prüft.
du müsstest mal bei Strato nachfragen wieviel BCCs die erlauben.
Normalerweise bist du da limitiert (50 oder evtl 100).
Rein technisch weiss ich nicht wo da die Limitierung ist.
Ich hab da vor Jahren glaub maximal 50 Adressen wegen der Limitierung des Email Servers rausschicken können.