t-sql
-
Gesamte Inhalte
71 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von t-sql
-
-
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.
-
vor 1 Stunde schrieb cj_berlin:
aber immerhin db_creator hatte.
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.
-
vor 3 Stunden schrieb JEckersberg:
Erst mal Danke.
Den 1. Weg wollen wir nicht.
Die Applikation soll auf einem Server bleiben. Dort sollen keine Veränderungen vorgenommen werden.
Deswegen der 2. Server.
Es klappt ja auch wunderbar. Ich habe verschiedene Datenbanken auf dem 2. Server eingerichtet. Jeweils mit unterschiedlichen Rechte von Nutzergruppen.
Wenn ich dich richtig verstehe, soll ich direkt auf den Server1 zugreifen. Dann müssen aber die Rechte auch entsprechend angepasst werden - oder?
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.
-
1
-
-
-
Sieht aus, als ob da ein Zertifikat abgelaufen wäre.
-
Am 7.12.2023 um 16:01 schrieb Nobbyaushb:
Moin,
läuft das auf Physik oder einer VM?
Was mich stört:
Warum hat der nur 8GB RAM? - wie man sieht, werden über 9GB auf Disk ausgelagert
Wird kein aktuelles OS unterstützt, Server 2022?
Die Platten finde ich extrem klein - was sind das? (siehe erste Frage...)
Und dann würde ich auch einen aktuellen SQL verwenden, wenn man das schon mal umziehen möchte
Natürlcih nur mit dem Hersteller-Support
Ggf. kann sich auch der Kauf eines SQL rechnen, wenn man Arbeitszeit gegenrechnet (ja, muss man...)
Die Vollversionen haben nicht die Einschränkungen von der kostenlosen Express-Version
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.
Am 7.12.2023 um 14:38 schrieb BWendle:Was mir bei der SQL-Datenbank der Software auffällt, ist das diese fast 8,5 GB groß ist aber beim auslesen der Datenvolumen der enthaltenen Tabellen, diese gesamt nicht mal 200 MB umfassen. Auch ist mir das hohe Datenvolumen der Transaktionsprotokolle aufgefallen. Hier habe ich schon ein vollständiges Backup der DB durchgeführt.Das Transactionlog wird durch eine Vollsicherung nicht geleert. Ein gängiger Irrglaube.
Am 7.12.2023 um 15:45 schrieb Dukel:Evtl. wäre auch zu überlegen, ob man den Modus auf Simple stellt, dann muss man sich nicht um T-Log kümmern.
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.
-
Am 19.9.2023 um 09:45 schrieb Nobbyaushb:
An dem neuen Server auch?
Ich habe in meiner Spiel-Umgebung zu Hause 10G im Backbone...
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.
-
Am 8.9.2023 um 10:50 schrieb cj_berlin:
Aber bei nahezu allen Clustering-Konzepten ist die 2-Knoten-Config ein Sonderfall. der mal besser, mal schlechter beschrieben ist.
Nö, 2 Knoten Config ist kein Sonderfall sondern eher die Regel. Und Microsoft beschreibt das sogar ziemlich gut in deren Dokumentation.
-
vor 8 Stunden schrieb q617:
Ein Laptop als Backupziel? Warum keine moderne Cloud-Lösung?
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.
-
Am 11.9.2023 um 15:15 schrieb zahni:
Nicht nach meiner Erfahrung. Wir verwenden viel Java-Software.
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.
-
vor 57 Minuten schrieb q617:
Und ein SQL-Server-Dienstleister kann deine DSL-Leitung schneller machen, damit die Vollsicherung schneller hochgeladen wird?
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?
-
vor 3 Stunden schrieb gerd33:
Oder sehe ich da etwas falsch??
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.
-
Am 30.8.2023 um 16:41 schrieb zahni:
Wir sollten hier mal klären:
Üblich ist SQL-Authentifizierung und seltener integrierte Windows Authentifizierung.
Nur das es genau umgekehrt ist.
-
Am 30.8.2023 um 12:07 schrieb q617:
Der Test mit dem SSMS war auf dem Server direkt, oder?
Die "neueren" SQL-Server machen standardmässig Verschlüsselung (glaub ich), hast du testweise mal SQL 2012 express probiert?
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.
-
vor 6 Stunden schrieb Dukel:
Wieso das Log Backup nur in die Cloud?
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.
-
vor 46 Minuten schrieb gerd33:
Endlich hat es geklappt. Mein Fehler war wohl, dass die Vollsicherung von einem anderen Rechner (SQLServer 2014) übernommen wurde und die differenzielle Sicherung auf dem neuen Rechner mit SQLServer 2022 erstellt wurde. Die Vollsicherung hatte alsm Eigentümer "NT-Authority, die differenzielle Sicherung hingegen "sa". Könnte evtl. die Ursache gewesen sein. Nachdem ich die Datenbank vom alten Server auf den neuen Server portiert hatte (unproblematisch) habe ich dort erneut eine Vollsicherung gemacht, mehrere Datensätze geändert und dann eine sequenzielle Sicherung durchlaufen lassen. Das Zusammenführen der beiden Sicherungen im Management Studio klappte dann problemlos. Verwundert hat mich nur, dass sowohl die Voll- als auch die differenzielle Sicherung im Rücksicherungs-Fenster im Management-Studio jeweils die Reihenfolge "1" hatten. Hat aber die Rücksicherung nicht beeinträchtigt. Ob es Sinn macht, eine zusätzliche Transaktionsprotokoll-Sicherung turnusmäßig durchlaufen zu lassen, weiss ich nicht, der Sinn erschließt sich mir nicht. Danke für eure Unterstützung,Gerd
Nur ums zu verstehen: Du hast deine Vollbackup von SQL Server 2014 im SQL Server 2022 wiederhergestellt (portiert ist hier der falsche Terminus, die Datenbank wird nicht portiert, sondern höchstens importiert. Dann kein Fullbackup erstellt sondern gleich das differenzielle Backup angeschmissen (wenig sinnvoll, Stichwort Backup Chain). Immer zu erst ein Fullbackup und dann die nachfolgenden. Der Eigentümer hat damit nichts zu tun. Zum Punkt Transaktionsprotokoll Sicherung: Brauchst du nicht, wenn deine Datenbank auf Simple Recovery steht. Sollte sie jedoch auf Bulk oder Full Recovery stehen, empfehle ich Dir dringend dich in das Thema Backup & Restore von SQL Server Datenbanken einzulesen, da hier ein Know How Defizit besteht. Is ja dann nur eine Frage der Zeit wann deine Datenbank/Verfahren stehen bleibt. Sequenzielle Sicherung gibt es im SQL Server nicht: Es gibt Full, Diff und Transaction. Dann noch eine Info, die du wohl überlesen hast: Es kommt der Punkt wo die differentielle gleich oder größer als deine eigentliche Datenbank ist. Warum ist das so? Beim differenziellen werden IMMER die Änderungen der Datenbank gespeichert NICHT die Änderungen zwischen zwei differentiellen Backups.
-
1
-
-
vor 23 Stunden schrieb jesada:
Versuch 1:
Nach dem Herunterfahren der SQL Server Rolle (Instanz), habe ich den Ordner kurz umbenannt, mit dem Versuch, dass diese beim Start dann nicht benötigt werden oder im Stammverzeichnis angelegt werden. Leider ist dann die SQL Server Instanz nicht mehr hochgefahren. Somit war der Punkt dann nicht zielführend.
Versuche 2:
Ich habe die SQL Rollen auf allen Nodes entfernt. Danach habe ich die SQL Rolle wieder installiert mit dem neuen Ziel. Die Datenbank wieder eingespielt und die Nutzer wieder auf der Instanz angelegt. Hat reibungslos funktioniert.Wenn es keinen offiziellen Weg gibt diese zu machen, könnte das ein Ansatz sein. Nachteil, die Datenbank ist für diesen Prozess, bis der erste Node Online ist, nicht erreichbar.
Danke für eure Hilfe
Grüße
Zu 1: Logisch das dies nicht geht. Die Pfade der Datenbanken sind in der Master hinterlegt und werden nicht automatisch angepasst. Google einfach mal "sql server move system databases". Das kann Dir da vielleicht helfen. Zu 2. Wer sagt denn das dies nicht der offizielle Weg sei? Hier model_msdbdata and log, model_replicatedmaster and log – What are they? – Opinionated SQL (seangallardy.com) steht was sie sind und wie man sie verschiebt.
-
1
-
-
Am 9.8.2023 um 09:05 schrieb Dukel:
Wieso sicherst du nicht das Full und Diff Backup in ein einzelnes Backup File?
@DukelWeil das eine ziemlich schlechte Idee ist und auch von niemanden empfohlen wird.
@gerd33 1. Wieso machst Du differenzielle Backups? Irgendwann sind die gleichgroß oder größer als die eigentliche Datenbank. 2. Was für Fehlermeldungen bekommst Du denn? 3. Wie machst Du den Restore? Über das SSMS? 4. Backups können immer in die aktuellste SQL Server Version aus einer älter zurückgesichert werden. Da gibt es keinerlei Kompatibilitätsprobleme.-
1
-
-
vor 21 Stunden schrieb jesada:
Wir betreiben jedoch verschiedene Instanzen (Kritisch bis unkritisch) für mehrere Mandanten, diese betreibe ich ungern in einer Instanz.
Wenn ihr das so macht, ist das erstmal ein Designfehler. Man sollte die kritischen in EINER Instanz bündeln, die unkritischen in einer anderen und diese selbstredend auf zwei verschiedenen Clustern betreiben. Wenn denn bei den unkritischen überhaupt ein Cluster notwendig ist. Eure Idee macht es einfach nur unnötig kompliziert, Wartung ist viel zu aufwendig, Resourcenverteilung usw. Es spricht eigentlich nichts für eure Idee. Es sei denn ihr habt kein Geld um es gscheit zu machen. Für Mandanten braucht man auch keinerlei eigene Instanzen, es sei denn es muss systemweit eine Einstellung gemacht werden. Die Trennung der Mandanten erfolgt logischerweise über das Berechtigungsmanagement des SQL Servers. Aber seis drum. Manche Leute wollens halt möglichst kompliziert haben.
-
1
-
SQL Datenbank für externe MA
in MS SQL Server Forum
Geschrieben
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.