t-sql

Du mußt den Microsoft Distributed Transaction Coordinator Dienst aktivieren.

Da fehlt wohl noch der Fehler

Du redest von sowas hier Peer-to-Peer Transactional Replication - SQL Server | Microsoft Learn. Aber das ist für diesen trivialen Fall ganz sicher nicht gedacht. Warum Standortdaten an anderen Standorten geändert werden sollten erschließt sich mir nicht.

Nur mal so als Anmerkung zur angeblich "besten Lösung": Dieses Vorgehen ist einfach nur falsch. Man arbeitet da mit passenden Accounts. Der Dienst läuft mit dem passenden Account, der auch im SQL Server mit den entsprechenden Rechten angelegt ist. Dann braucht man auch nix an SYSTEM rumzuschrauben. Das ist nur Pfusch.

Nein, da hab ich nix verwechselt. Im SQL Server Configuration Manager können und müssen die Dienstaccounts gesetzt werden. Das ist bei Microsoft auch dokumentiert. Das anders zu machen wird von Microsoft nicht empfohlen. Natürlich mußt Du auch das richtige anklicken. SQL Server Services, Rechtsklick auf SQL Server -> Properties. Dann isses schon der erste Reiter.

Bin mir gerade net sicher, ob ich dein Problem verstehe. Bei der Installation im ersten Screenshot hast ja den lokalen Administrator schon mal als Sysadmin hinzugefügt. Ohne gehts auch nicht weiter. Also haste Zugriff auf den SQL Server. Dienstaccounts kannste mit dem SQL Server Configuration Manager setzen.

Da spricht überhaupt nix dagegen. Nö, da is nix absurd dran. Proxmox is halt auch nur in Virtualisierer wie VMware auch und den Hypervisor kann man selbstredend auf einem Server laufen lassen. Was du meinst sind Funktionen, die nur auf mehreren Servern Sinn ergeben. machst du dich da bitte nochmal schlau? Hardware Raid wird sehr wohl von Proxmox unterstützt.

Proxmox (das gleiche wie VMware) sind wir am testen. Datacore funktioniert bei uns tadellos (mehrere PB). Nur brauchste dafür halt auch ein SAN um Datacore nutzen zu könnnen. Was meinst Du eigentlich mit "Clusterbetrieb mit hoher Verfügbarkeit"? Wenn es um Verfügbarkeit geht, mußt du auf vieles achtet. erstmal mußt festlegen wie hoch deine Verfügbarkeit sein soll bzw. wie gering deine Downtime sein darf (das muss alles die Firmenleitung festlegen) muss dir klar sein, das Hochverfügbarkeit per se teuer ist, 98,5% = knappe 6 Tage Downtime, 99% = 3,6 Tage, 99,9% = 8,7 Std. je mehr Neunen desto teurer und zwar exponentiell, deine ganze Infrastruktur muss darauf ausgelegt. Server mit mehrerern Netzwerkkarten/Ports, reduntant ausgelegte Switche, Router usw., das SAN muss dafür natürlich auch ausgelegt sein. Also brauchste dafür schon mal beim SAN Storage alles doppelt. die Wiederherstellung liegt ja bei Dir. Du mußt ein Backupkonzept erstellen, deine Bosse müssen sich über RTO und RPO Gedanken machen dann kannst auch was über Wiederherstellungszeiten sagen namhafte Hersteller (z.B. DELL, HPE). Da brauchste mit Wortmann oder Thomas Krenn net anfangen brauchste natürlich einen gscheiten Wartungsvertrag mit dem Hersteller mit entsprechenden Reaktions- bzw. Entstörzeiten wenn du bei einem davon das Sparen anfängst dann kannste deine Hochverfügbarkeit gleich in die Tonne kloppen Interessanter Ansatz: Also am besten keinerlei Server ins AD aufnehmen und somit maximalen Verwaltungsaufwand betreiben. Ziemlich fern jeglicher Realität deine "Idee".

Morgen @roccomarcy dbatools sind dein Freund. Das ist eine Powershellerweiterung, die genau dafür bestens geeignet ist.

Morgen Gerd, ich würde zu erstmal prüfen ob der Netzwerktraffic passt. Also in deinem VPN alle benötigten Ports auch an allen Clients in beide Richtungen durch kommen. Weil wenn VPN funktioniert und keinerlei Regeln irgendwas blockieren dann muss das gehen. Da brauchste auch keinerlei DNS oder sowas. Außerdem solltest Du schauen ob bei deinen Clients der SQL Server auch auf die VPN IP horcht. Was er vermutlich nicht macht.

Hallo in die Runde, wir sind dabei auf einem Fileservice Cluster die Performance zu prüfen. Dabei haben wir auch ordentlich SMBserver Events 1020 gefunden. In dem Event steht u.a. ein Warning Threshold für den Dateizugriff drin. Der Standard ist wohl 15000 ms. Steht auch bei dem einen drin. Auf dem anderen Knoten steht dort leider 120000 ms drin. Weiß jemand wie man den Wert ändern kann? Grüße

Hallo @lizenzdoc kannst Du dazu mal ein Microsoft Dokument verlinken? Beim offiziellen Microsoft Lizenz Guide von SQL Server steht von Windows Server Cals nix drin.

Ergibt absolut keinen Sinn. Denn wozu brauch ich ne Server CAL wenn ich mich nicht mal am Server selbst anmelden kann und nur der Port 1433 überhaupt erreichbar ist? Aber bei Microsoft mag das so sein. Dann kann für dich @magicpeter nur die Empfehlung sein den SQL Server auf einer Linux Büchse zu installieren. Somit fallen deine 20 Server CALs schon mal weg.

Interesant finde ich eher die Frage: Werden die Server CALs benötigt wenn die Benutzer sich nur am SQL Server anmelden?

Is zwar schon ne Weile her, der Post: Auf meinen Windows Server 2025 gibt wmic immer noch.

Zur Info https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/permissions-on-copying-moving-files

Müssen denn die Datenbanken nicht synchron gehalten werden? Hier kannste mal anfragen DeutschlandLAN Connect IP | Telekom Geschäftskunden.

Hallo @magicpeter, 1. die Anbindung für so ein Vorhaben ist ein Witz. Da brauchste schon eine synchrone Anbindung, 2. die Verbindung zum SQL Server über VPN ist kein Problem. Verbindungsprobleme dabei sind nur Netzwerkprobleme und hat mit SQL Server nix zu tun, 3. Nimmst du TCP/IP und nicht Named Pipes als Provider, 4. brauchste dir bei der Anbindung keine Hoffnung auf Performance zu machen, 5. ist mir klar, das der Kunde kein Geld in die Hand nehmen will um das gscheit zu machen. Sind die beiden Standorte völlig unabhängig von einander oder ist die WW für beide Standorte gedacht?

Kannst Du mal den View hier einstellen? Bekommst Du eine Fehlermeldung?

Reine T-SQL Lösungen sind übersichtlicher. Powershell ist zu umständlich und dbatools (was die einzige Powershellalternative zu T-SQL wäre) darfste halt auch net auf jedem Server installieren. Außerdem viel zu umständlich mit SQL Agent auszuführen. Taskscheduler kannste in die Tonne kloppen weil faktisch keine Flexibilität.

Maintenance Pläne gehen in einer Contained AG nicht. Maintenance Pläne sind eh nicht das gelbe vom Ei. zu unflexible. Für die gängisten Wartungen sind die Scripte von Ola Hallengren die besten (ola.hallengren.com). Da haste auch keine Probleme mit den AGs. Als DBA solltest dich mit T-SQL auseinandersetzen. Da isses wichtig DMVs und System Tabellen zu kennen. Denn das meiste kannste eben nicht mit einem Maintenance Plan abdecken

Nö, alte Daten sind ja kein Grund. Und auch sonst gibt keinerlei Gründe Datenbanken zu schrumpfen.

@CBonnkirch Was zeigt denn der Report Disk Usage bzw. Disk Usage by Table im SSMS? Mal abgesehen davon, das es eigentlich faktisch keinen Grund gibt um Datenbanken zu verkleinern.

Eventuell wäre dann für dich der SQL Server 2025 interessant. Kommt aber erst noch raus

@Hellwege Mir kommts bisserl so vor als ob du deine Hardware solange laufen lässt bis sie kaputt geht. Also weit über der Support/Garantie Zeit hinaus. Logisch das dann die Verfügbarkeit sinkt bzw. nicht mehr vorhanden ist. Im Profibereich wird die Hardware nach Ablauf des Supports/Garantie getauscht. Schließlich ist ein gscheiter Support mit entsprechender Reaktions-/Entstörzeit essentiell im Profibereich. Da solltest besser ansetzen.