t-sql

Hi, passt die SSMS Version zur SQL Server Version?

Ja, stimmt. Aber wenn der User keinen Zugriff auf die Datenbank hätte, sich aber anmelden dürfte steht das "Login failed for user 'MY-PC\MyName'. Reason: Failed to open the explicitly specified database. [CLIENT: ]" im Errorlog und nicht das das falsche Passwort bei der Application genutzt wird.

Dann wäre die Meldung im Errorlog eine andere.

Was steht denn im Errorlog des SQL Servers drin? Wenn sich der User nicht anmelden kann steht drin warum. Und um Logins von einem SQL Server zum anderen zu transportieren gibt es eine Stored Procedure von Microsoft (Transfer logins and passwords between instances - SQL Server | Microsoft Learn)

Das ist schon mal ein Denkfehler. Datenbankserver machen nix anderes als Datenbanken bereitzustellen. Rechenleistung für Anwendungen haben darauf nix verloren. Dazu gibts Applikationsserver. Das gilt sowohl in House als auch in der Cloud.

Wie man sieht kannst Du gar kein SQL Server Backup machen weil Du keine Enterprise Lizenz hast. Also ist es fraglich, ob deine Datenbank überhaupt gscheit gesichert werden kann ohne das Feature, unabhängig ob Simple oder Full. Klick im SSMS mal auf die Eigenschaften der Datenbank und lass Dir das letzte Sicherungsdatum anzeigen.

Und mehr ist auch gar nicht nötig.

Eigentlich wird ja beim Restore immer das Login des Wiederherstellers als Datenbankbesitzer (nicht zu verwechseln mit der db_owner Rolle) eingetragen. Dann haste eh immer volle Rechte auf die Datenbank. Schau mal nach was beim Owner nach dem Restore drin steht.

Da hatte ich wohl einen Zahlendreher drin. Server2 ist auf Server1 als Linked Server eingerichtet und du willst die Daten von Server1 auf Server2 abfragen. Wenn Du den Linked Server behalten willst dann kannst du natürlich die Views auf dem Server1 bauen und auf Server2 abfragen. Ansonsten ist die beste Methode ganz auf Linked Server zu verzichten und von der Applikation direkt auf die Daten zuzugreifen.

Um mal einen kompetenten (Brent Ozar) mit einzubringen. Keine Linked Server nutzen sondern von der Applikation auf den zweiten Server verbinden und in der Applikation das ganze verarbeiten. Oder ihr baut die Views auf Server 2 und rufst sie über Server 1 auf. Das geht auch

Oder: Dein Kunde wechselt einfach zu einem professionellen Anbieter und nimmt keinen Consumer Anschluss.

.

Sieht aus, als ob da ein Zertifikat abgelaufen wäre.

Leider völlig am Thema vorbei. Für eine DB die kein Gigabyte groß ist reichen 8 GB völligst aus. Für was sollen die Platten größer sein? Brauchen die nicht. Vollversion SQL Server ist bei der Anwendung auch völlig überzogen. Das Transactionlog wird durch eine Vollsicherung nicht geleert. Ein gängiger Irrglaube. Das stimmt nur bedingt. Wenn eine Transaktion aktiv ist und lange läuft platzt dir auch bei Simple Mode das Transactionlog. @BWendle Schau bitte in das Errorlog deines SQL Servers nach. Da könnte was drin stehen.

Und? Was willste uns damit jetzt sagen? 1 GB is nachwievor üblich. Ne 10 GB Umgebung bekommt ja nicht gerade beim Discounter, nicht wahr.

Bei der Lösung verstehe ich den ersten Punkt nicht. Ein User der auf einen SQL Server zugreifen will braucht NIE in einer lokalen Gruppe des Windows Servers zu sein. Außerdem sind deine Rollen für die Broker Gruppe unnötig. In Public is eh jeder User automatisch drin, sysadmin hat eh alle Rechte und braucht damit die dbcreator Rolle gar nicht.

Nö, 2 Knoten Config ist kein Sonderfall sondern eher die Regel. Und Microsoft beschreibt das sogar ziemlich gut in deren Dokumentation.

Was brauche ich eigentlich für eine Anbindung in die Cloud um dort ein sicheres und performantes Backup abzubilden? Reicht da 1 GBit/s? Wie muss das eingerichtet sein? Über einen POP oder zwei verschiedene POPs der Redundanz wegen? Welche Bandbreite ist bis zu welcher Backupgröße eigentlich sinnvoll? Cloud is schon geil. Scheiße nur wenn der Bagger gerade das Kabel durchgebaggert hat. Aber ich hab ja 99,999% Verfügbarkeit, im Cloud Datacentre. Nur nicht bis zur mir selbst.

Siehste. ist halt in deinem Kontext so. Bei uns isses genau umgekehrt. Daher einfach net pauschale Aussagen über sowas machen. Außerdem ist Best Practice eben keine SQL Authentifizierung zu nutzen.

Ich weiß, das ist schwer vorstellbar. Vielleicht, aber nur vielleicht könnte ja ein Consulting Unternehmen genau das machen: Consulting und ein anderes Backupkonzept erstellen? Könnte doch sein, nicht wahr?

Ja, siehst du. Sicherungen können in einer Datei zusammengefasst werden (wie @cj_berlin schon erwähnte), is aber Blödsinn. Sicherungen egal, ob full, inc., trn laufen immer in separate Dateien. Mußte aber entsprechend einstellen. BTW. versteh ich immer noch nicht warum man auf Gedeih und Verderb so eine große Sicherung in die Cloud hochlädt. Und eins noch: Ein Backup taugt nix solange Du den Restore nicht übst.

Nur das es genau umgekehrt ist.

Nein machen sie nicht, auch nicht die ganz neuen. Dazu muss ein Zertifikat installiert werden. Es macht erstmal keinen Unterschied ob die Verbindung auf dem Server oder von einem Client aufgebaut wird.

Am besten machst Du erstmal folgenden Versuch: Kannst Du dich mit einem Mitglied der Gruppe "OAS_Admin" per SSMS an dem SQL Server anmelden? Wenn ja gibts kein Problem mit dem Datenbankserver -> Applikationsproblem.

Ein Log Backup macht er ja nicht. Differenzielles Backup != Transaction Log Backup. @Gerd33 Da is noch einiges an Defizit da (net abwertend gemeint). Hol Dir mal bisserl Consulting ins Haus oder lies dich da mal echt ein. Wenn ich lese Anbindung von Medizingeräten sollten die Datenbanken auch ein robustes Backup haben. Das fehlt hier.