t-sql

Ja, der Unterschied besteht allerdings. *.mdf Dateien sind eben die Dateien der Datenbank, wobei es nur eine MDF Datei gibt (so eine Art Bootpartition der Datenbank). Und *.bak sind eben Backupdateien. Die werden benötigt um eben eine Datenbank wieder herzustellen. *.bak Dateien enthalten eine konsistente Version deiner Datenbank zum Zeitpunkt x. *.bak Dateien können NICHT einfach eingehängt werden, so wie das mit *.mdf Dateien geht. Was fürn Problem hast Du denn? Welchen Fehler bekommst denn?

Nein, kann sie nie. Wenn Du den neuen Server mit 128 GB RAM anschaffen kannst, mach das. Die Aussage deines Schlaumeiers is natürlich quatsch. Aber wenn dein Server unter Memory Pressure leiden würde, dann siehst du das auch Errorlog. Da solltest mal reinschauen. Und nein. Memory Pressure bedeutet NICHT, das der SQL Server sich den ganzen RAM klaut. Das ist völlig normal.

Das sichert dir aber nicht zu, dass das Backup bzw. der Restore funktioniert.

Nee, muss er nicht. Ein Reboot ist genau das.

Ja, steht auch explizit in dem Microsoft Artikel drin. Also an alle anderen: In einer produktiven Umgebung benutzt man nur und ausschließlich unterstützte Konfigurationen. Der Native Client ist deprecated und die Alternative ist der OLEDB oder ODBC Treiber. Beide sind supported. Das was Dutch_OnE hier macht, kann gehen, muss aber nicht. Wenn man nicht unterstützte Konfigurationen/Software einsetzt, braucht man sich über nix wundern. Einfach richtig machen

Es geht um VSS Snapshots. Das unterstützt die Express Version. Ist bei der Netzwerkeinstellungen für TCP/IP "Listen All = YES"? Wenn ja, sollte die Verbindung gehen. Prüfe mal, ob Du von einem anderen Rechner per Telnet auf den Port 1433 (Standardport für SQL Server) drauf kommst. Falls ja, prüfe ob Du dich mit dem SSMS remote auf den SQL Server verbinden kannst. Braucht deine Backupsoftware noch irgendwelche Einstellungen? Das muss ja in der Doku dazu drin stehen.

Mahlzeit, ganz einfach. 1. Backup machen, 1a. mit Restore Headeronly testen ob, der Restore grundsätzlich geht 2. Datenbank regelmäßig mit dem erstellten Backup wiederherstellen. Ich geh einfach mal davon aus, das auch Transactionlogs gesichert werden.

Hallo Peter, das Vorgehen ist immer das gleiche: Erst den passiven Knoten patchen, durchbooten und schwenken. Es ist nicht nötig den passiven Knoten auf Pause zu setzen. Die Platten braucht ihr nicht anfassen. Beim Schwenken bitte Geduld mitbringen. Es kann dauern bis der SQL Server wieder oben ist. Falls was schief läuft immer ins ERRORLOG des SQL Servers schauen. Da steht in der Regel drin was nicht passt. Aber Nils hat schon recht. Ihr müßt euch das Know How holen oder selbst aneignen.

Is ja auch klar. Laufwerke bei Windows werden immer im User Kontext gemappt. Heißt, es muss ein User angemeldet sein damit du überhaupt ein Laufwerk mappen kannst. Daher kann das bei Serverstart gar nicht gemappt werden. Als Krücke könntest Du dich natürlich mit dem Serviceuser des SQL Server Agents anmelden und so das Laufwerk mappen. Aber da SQL Server problemlos auf Shares das Backup erstellen kann isses eben eine Krücke und nicht notwendig.

Programmierkenntnisse brauchst net unbedingt. Aber Windows Admin Kenntnisse sollten da sein und einen DBA brauchst auch, für das Backup der Datenbank. Um FTP machen zu können brauchst auch noch einen FTP Server. Sonst geht da nix.

1. SET NOCOUNT ON ist nicht nur für DML gedacht. 2. Nimmst Du den PHP Treiber von Microsoft? Wenn ja, passt dieser auch zur ODBC Version? 3. Werden im Profiler 956 oder 322 Zeilen beim Aufrufen aus PHP heraus angezeigt?

Das ist natürlich zutreffend weil wir genau diesen Fall hatten und von MS hieß es: Lizenz für beide bezahlen. Sry, aber du rechtfertigst ja noch das falsche Vorgehen

Richtig machen heißt nicht "reine Lehre". Wenn die Aufgabe darin bestand SQL Server 2022 auf einem bestehenden Server mit SQL Server 2012 zu installieren dann fragt man vorher ob, man den deinstallieren kann. Offensichtlich wusste ja der Dienstleister nicht was er tut. Die Aussage "es könnte durch entfernen eine alten Version spezielle Runtimes der aktuellen Version entfernt werden." geh ich mit wenn man die alte Version drauf lässt. Aber nicht wenn der alte sauber deinstalliert wurde. Was bei dem Vorgehen passieren kann? Ein inkonstentes System, Im Config Manager werden auch die anderen Dienste angezeigt, disabled aber da. Dann kommt die Frage "Warum sind die deaktiviert?". Jemand anders fährt die deaktivierten Dienste hoch usw., usw.. Eine Überwachung prüft den SQL Server Dienst. Der neue hat den gleichen Namen wie der alte. Welcher ist nun der korrekte? Parallele Neuinstallation von SQL Server ist NIE notwendig. Außerdem hab ich noch die Lizenzfrage vergessen. Muss man für einen deaktivierten SQL Server ebenfalls Lizenzkosten zahlen? Sprich zwei SQL Server Installationen, zwei mal Lizenzkosten. Windows Server Inplace Upgrade würde ich auch nicht machen. SQL Server Inplace, kein Problem. Was issn IU?

Hallo @Dutch_OnE, 1. was genau haben die gemacht? den SQL Server 2022 zusätzlich installiert oder ein Inplace Upgrade des SQL Server 2012 gemacht? 2. Falls die SQL Server 2022 neben 2012er installiert haben und danach den 2012 deaktiviert haben war das Vorgehen völlig falsch und mehr als amateurhaft. Schließlich deinstalliert man VOR der anderen Installation den 2012er und dann passiert auch nix. 3. Such dir ne Firma die sich auch wirklich mit SQL Server auskennt. Dein aktueller Dienstleister kennt sich damit anscheinend nicht aus. Was fürn "Zusatzaufwand" wäre es denn es richtig zu machen? Sprich VOR der Installation des SQL Server 2022 den alten runterzuschmeißen. Das ist der korrekte Weg. Ich hätte meinen Mitarbeitern gesagt: 1. Macht vorher ein Backup der Datenbanken, 2. deinstalliert dein 2012er, 3. installiert den 2022er. Dann sag ihnen sie sollen es nochmal machen und dann auch richtig.

Ihr nehmt SSIS. Also isses net zeitkritisch. Ich würd da mit Logshipping anfangen. BTW. der SQL Server Replikation is die Datenbankstruktur völlig wurscht.

Nee, du meinst: Gibts umsonst aber net kostenlos. So wird n Schuh draus.

Alles klar. Dann installier mal die aktuellste OBDC Treiber Version für den SQL Server, aktuell 181.2.1 Vermutlich nur ein Schreibfehler von Dir. Seis drum. Die Servicepacks gibts umsonst

Dann ist die erste Maßnahme die Kiste mal auf SP3 zu heben

Das ist leider für das Szenario nicht geeignet. Schließlich ist Always On eine HA Lösung. Außerdem meinst Du sicherlich Always On Availability Groups und nicht Always On Failover Cluster. Das Szenario funktioniert nur mit Copy Only Backups. Oder es wird zeitgesteuert aus der Backuplösung ein Restore gemacht.

Die Pivot Funktion ist da genau das Richtige.

Ich würde da mit ltrim() und rtrim() arbeiten.

Wir bekommen diese Meldungen immer wenn Passwörter der zugehörigen Domain User abgelaufen sind. Soll heißen: Passwort wird geändert, User is noch irgendwo mit dem alten Passwort angemeldet. Im Endeffekt isses erstmal nix dramatisches.

Nö, wumpe isses net. Support hat nix mit Netz tun oder nicht. Software betreibt man, gerade in einer Produktivumgebung (wovon ich mal ausgehe), IMMER mit Herstellersupport. Alles andere ist fahrlässig. Tritt ein Fehler auf, dazu solltest du dir mal durch lesen was alles in SP3 gefixt wurde, kriegste halt keine Lösung, fertig. Heißt im besten Fall stehen halt deine embedded Maschinen. Und ich hoffe, dein Kunde will veraltete Software einsetzen und ihr habt ihn nicht falsch beraten.

Deinem Kunden is hoffentlich klar, das es in knapp einem Monat keinerlei Support mehr für SQL Server 2016 SP2 geben wird

Das war mir auch klar. Nur deine Frage ist falsch gestellt. PS mit T-SQL zu vergleichen, was deine Frage ja impliziert, ist wie Äpfel mit Birnen. @LTTG | @LTTG2 probier mal den Port 25 anstatt 587