NilsK
-
Gesamte Inhalte
17.149 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von NilsK
-
-
Moin,
hast du den Link gelesen, den ich gepostet habe?
Es handelt sich um Systemdatenbanken, die bei einer bestimmten Installationsvariante mit angelegt werden. Diese dienen aber nur als Vorlagen für neue Datenbanken, genau wie die model-Datenbank. Sie werden also nicht aktiv genutzt und wachsen somit auch nicht an. Daher gibt es keinen Grund, sie zu verschieben.
Was du mit "versteckt" meinst, erschließt sich mir nicht, ist aber auch nicht so wichtig.
Gruß, Nils
-
Moin,
[OT] mir fällt bei sowas immer der Garbage Collector des C64 ein, der das System minutenlang - oder auch dauerhaft - lahmlegen konnte. Den konnte man auch triggern (PRINT FRE(0)), aber das war keine Freude.
[/OT]
Gruß, Nils
-
1
-
-
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.
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.
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
-
1
-
-
Moin,
vor 18 Stunden schrieb daabm:Sonst könnte man ja in der lokalen GPO Werte setzen, die eigentlich von Domain GPOs anders gesetzt werden... Das führt dann die Inheritance ad absurdum.
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,
vor 32 Minuten schrieb teletubbieland:Das geht so, seitdem MS mehr Teams verkaufen will...
wieso, bis wann wollten sie denn das nicht?
Gruß, Nils
-
Moin,
vor 44 Minuten schrieb cj_berlin:Compute und Storage auf verschiedenen Knoten
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
-
1
-
-
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
-
1
-
4
-
-
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,
vor 8 Minuten schrieb LK28:Du wirst gezwungen in den ellenlangen Threads mehrmals zu antworten?
bei den Experts tauchen manchmal so finstere Typen mit langen Messern auf, wenn man nicht antwortet. Echt kein schöner Job.
Gruß, Nils
-
2
-
-
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
-
2
-
-
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.
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
Versteckte Datenbank umziehen Speicherort
in MS SQL Server Forum
Geschrieben
Moin,
ich kann dir nicht folgen. Von der Instanz auf ein Share ...? Heißt was?
Das musst du ja auch nicht. Das sind keine Benutzerdatenbanken.
Gruß, Nils