NilsK

Moin, hier habe ich die Grundlagen mal ausführlich zusammengefasst: [SQL Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net] https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Zugegebenermaßen ist der Teil, nach dem du fragst, etwas knapp geraten. Dazu findest du hier aber mehr - ist eigentlich auch sehr leicht zu finden. https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/restore-a-differential-database-backup-sql-server?view=sql-server-ver16 Ich würde an deiner Stelle aber noch mal schauen, ob das Verfahren das richtige ist. Das kann sein, aber vielleicht ist auch eine Kombination mit Log-Backups günstiger. Gruß, Nils

Moin, diesem Thread nach zu urteilen, ist es nicht vorgesehen, diese Datenbanken zu verschieben. Das dürft aber auch völlig unnötig sein, weil es sich nur um Vorlagen handelt. https://learn.microsoft.com/en-us/answers/questions/852800/model-replicatedmaster-ldf-move-to-another-drive Gruß, Nils

Moin, bitte lass diesen Thread nach viereinhalb Jahren ruhen. Wenn du konkrete Fragen hast, dann stelle diese bitte in einem neuen Thread und formuliere sie möglichst deutlich und ausdrücklich. Gruß, Nils

Moin, klar, aber bis zu deiner Erwähnung war ich der Meinung, dass genau diese Möglichkeit besteht. Man braucht ja schließlich lokale Adminrechte dafür, da kann sowas ja durchaus gewollt sein. Ich hätte auch behauptet, das geprüft zu haben, aber anscheinend war ich da im Irrtum. Wunderwelt Gruppenrichtlinien ... lernste echt im August 2023 noch was Neues dazu. Dabei kann ich mich noch ziemlich genau an das Train-the-Trainer im Sommer 1999 erinnern ... Danke und Gruß, Nils

Moin, Auch nicht das lokale GPO? Wow, das lese ich nach 24 Jahren zum ersten Mal. Gruß, Nils

Moin, dass an der Stelle der Name nicht aufgelöst wird, ist normal bzw. oft so. Wenn man die Verbindung dann hinzufügt, geht die Namensauflösung normalerweise - wenn nicht noch was anderes schief läuft. Klappt das bei dir nicht? Gruß, Nils

Moin, ich interpretiere deine Frage so, dass du dir über die Grundlagen nicht ganz sicher bist. Vielleicht hilft Folgendes - schon ziemlich alt, aber immer noch gültig. [Die Anwendung von Gruppenrichtlinien steuern | faq-o-matic.net] https://www.faq-o-matic.net/2014/04/07/die-anwendung-von-gruppenrichtlinien-steuern/ [Erste Schritte - Gruppenrichtlinien] https://www.gruppenrichtlinien.de/themen/erste-schritte Gruß, Nils

Moin, wieso, bis wann wollten sie denn das nicht? Gruß, Nils

Moin, das wäre hier gar nicht gegeben. Ein CSV ist ja eine LUN aus einem (separaten) Storage-System. Die Zuordnung zu einem Knoten dient nur der Koordination der Zugriffe durch verschiedene Systeme. Möglicherweise verwechselst du das grad mit S2D. Gruß, Nils

Moin, die Frage ist, was du damit erreichen willst. Technisch betrachtet, kannst du das tun. Eine pauschale Empfehlung dafür kann man aber nicht aussprechen, weil so eine Aufteilung wohl nur in sehr speziellen Szenarien Vorteile brächte. Am Ende sind CSVs normale LUNs aus dem Storage. Anders als diese können aber mehrere Server gleichzeitig darauf zugreifen, eben die Cluster-Nodes. Es muss dabei sicher gestellt sein, dass diese nicht dieselben Daten verwenden. Rein technisch könnte man also durchaus die Dateien so aufteilen, wie du es angibst, denn es greift ja jede Instanz nur auf ihre Dateien zu. Bleibt aber die Frage, warum man das tun sollte. Interessant könnte das evtl. sein, wenn etwa das Log-CSV viel schneller im Zugriff wäre als das DB-CSV. Das dürfte allerdings bei den meisten Storage-Systemen gar nicht der Fall sein. Außerdem geht es dann evtl. nach hinten los, wenn mehrere Datenbanken ihre Logs auf demselben CSV haben und damit dann um die Zugriffe konkurrieren. Zudem ist das CSV die Failover-Einheit, aber da das eher die Verwaltung betrifft als die laufenden Zugriffe, ist das eher weniger relevant. Es ist eine Frage, die im Gesamtdesign des Systems zu beantworten ist, aber keinesfalls pauschal. Gruß, Nils

Moin, was würde denn aus deiner Sicht für getrennte CSVs sprechen? Mir kommt schon die Idee exotisch vor. Gruß, Nils

Moin, okay, dann passt es zu Admins. Die denken ja auch, wenn sie Monitoring machen, gibt es keine Ausfälle mehr. Gruß, Nils

Moin, möglich, dass das out of scope war. Wenn Admins jetzt auch noch fürs Wetter zuständig sein sollen ... Gruß, Nils

Moin, schon in der Bibel ist davon die Rede, und es gibt Forschungsmeinungen, die Hinweise darauf in Höhlenmalereien sehen. Gruß, Nils

Moin, Da ich eure Anforderungen nicht kenne, kann ich dazu nichts weiter sagen. Irgendwelche Analogien und Logikspiele führen hier nicht zu viel, denke ich. Gruß, Nils

Moin, Manche Entwickler arbeiten bei Microsoft. Gruß, Nils

Moin, welches A? Completely lost, Nils PS. eigentlich finde ich es schön, dass solche Fehler auch anderen passieren ...

Moin, bei den Experts tauchen manchmal so finstere Typen mit langen Messern auf, wenn man nicht antwortet. Echt kein schöner Job. Gruß, Nils

Moin, und es ist eben schlecht, um Hilfe zu fragen, wenn man nicht angibt, was man eigentlich erreichen will. Für's nächste Mal dann ... Gruß, Nils

Moin, ich glaube nicht, dass diese Diskussion weit führt, wenn wir weder das Datenmodell noch die Anforderungen kennen. Gruß, Nils

Moin, du hast es hier mit einem "Composite Primary Key" zu tun. Das ist zulässig, hat aber - wie du siehst - seine Nachteile. Um diese Nachteile aufzulösen, musst du das Datenmodell genau kennen und auch wissen, wie auf die Daten zugegriffen wird. Einfach so ändern kannst du das nicht, weil du damit die Grundlogik der Tabelle änderst. Heißt für dich also: Entweder den ursprünglichen Entwickler ansprechen oder viel Arbeit in die Analyse stecken. https://learn.microsoft.com/en-us/sql/relational-databases/tables/create-primary-keys?view=sql-server-ver16 Wenn du beides nicht tun kannst oder willst, müsstest du versuchen, deine Methode zum "Datenabgleich" zu optimieren (was auch immer darunter zu verstehen ist). Leider kann man an der Stelle wohl nicht viel mehr sagen, ohne viel Aufwand in die Problemanalyse zu stecken. Gruß, Nils

Moin, okay, das ist ja schon mal ein wichtiger Punkt. Ihr könntet also (so verstehe ich das) im AD gezielt auf einer OU (oder so) einer Mitarbeitergruppe das Recht geben, Computerkonten hinzuzufügen. Diese OU könnte das Standardziel für neue Computerkonten sein. Dann betreffen euch die Hinweise in dem KB-Artikel nicht. Ansonsten weist der KB-Artikel ja auch Wege auf, wie es mit dem Pre-Staging gehen kann. Da ich selbst kein AD betreibe und momentan auch keine passende Testumgebung habe, fehlen mir dort die konkreten Umsetzungserfahrungen. Aber für mich klingt es, als sollten sich die nötigen Gruppen und Policies recht einfach nutzen lassen. Gruß, Nils

Moin, und du möchtest jetzt einen Weg beschrieben bekommen, wie es geht? (Ernst gemeinte Frage, damit wir in die richtige Richtung diskutieren.) Falls ja, fangen wir mal einfach an: Auf das Pre-staging (Computerkonto vorher anlegen) zu verzichten, ist in dem Szenario keine Option? Gruß, Nils

Moin, was ist der Hintergrund deiner Frage? Geht es darum, dass du das ermöglichen möchtest? Oder geht es darum, das zu verhindern? Die Updates, die der Artikel beschreibt, betreffen nur ein bestimmtes Szenario, nämlich das (Wieder-)Verwenden eines bestehenden Computerkontos im AD. Sie betreffen nicht den üblichen Vorgang, einen Computer erstmalig ins AD zu bringen. Das funktioniert, soweit ich das sehe, immer noch so wie vorher. Gruß, Nils

Moin, Also, in Oberbayern haben wir diese Marke weit verfehlt. Warm, manchmal freundlich, manchmal Regen. Aber schon hübsch hier. Gruß, Nils