RE: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
Da sieht man eben mal wieder wer sehr Datenbank fit ist ;-) Ich bin es noch nicht, arbeite aber dran. Vielen Dank für deine Hilfe. P.S.: Kannst du mir dazu ein gutes Buch empfehlen? At 16:22 03.01.2004 +0100, you wrote: erm, nein, am besten du machst das mit dem Query Analyzer und nicht mit dem Enterprise Manager. Folgendes Skript sollte helfen: USE meineDatenbank GO EXEC sp_dboption 'meineDatenbank', 'autoshrink', true GO EXEC sp_dboption 'meineDatenbank', 'trunc.log on chkpt.', true GO BACKUP LOG meineDatenbank WITH TRUNCATE_ONLY GO EXEC sp_configure 'fill factor', 0 GO ALTER DATABASE RECOVERY SIMPLE GO Sorry für Tippfehler, das hab ich grad so aus dem Kopf runtergetippert... lG Peter > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Berner > Sent: Saturday, January 03, 2004 3:57 PM > To: [EMAIL PROTECTED] > Subject: RE: Whidbey (WAS: RE: [Framework.net] Re: > [Framework.net] > System.ComponentModel.Design.Serialization.DesignerSerializerA > ttribute) > > 'muss dich jetzt doch nochmal löchern: > > ich gehe im Enterprise Manager auf Verwaltung/Sicherung/Neues > Sicherungsmedium und dann? > > > > At 15:44 03.01.2004 +0100, you wrote: > > > > 194MB!!! > > > > > > Wie kann man sich das denn erklären? > > > Hast du da eine Idee? > > > > > > Viele Grüße > > > Lars > > > >Ja, typischer Fehler vieler SQL Admins: Logfile steht auf > unrestricted > >growth und du hast full recovery eingestellt. > >Ist beides unnötig. Mach mal ein BACKUP LOG logname TRUNCATE > ONLY damit du > >das riesen file los wirst und stell dann das logfile neu ein > mit anfang 2MB > >und Maximal 8MB das reicht voll... > > > >als nextes solltest du das Recovery Model der Datenbank auf > Simple stellen. > > > >Und danach deinen Test wiederholen um sinnvolle Werte zu > kriegen. Damit der > >Test auch Sinn macht: beim Löschen des Tabelleninhaltes > TRUNCATE TABLE > >verwenden statt DELETE, und nach dem befüllen unbedingt > entsprechend den > >Index defragmentieren und den FillFactor auf 0 stellen. > > > >Das sind alles Werte die für Spacetest sinn machen. Wenn du einen > >performance Test haben willst müßte man ein bisserl anders arbeiten. > > > >liebe Grüße > >Peter > > > >___ > >Framework.net mailing list > >[EMAIL PROTECTED] > >http://www.glengamoi.com/mailman/listinfo/framework.net > > > > > >--- > >Eingehende Mail ist zertifiziert virenfrei. > >Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). > >Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 > > > www.zoologie-online.de > > Lars Berner > Stormcrow-Software > Postfach: 110123 > 69071 Heidelberg > > Virus checked by G DATA AntiVirusKit Version: AVK 11.0.452 from 22.10.2002 Virus news: www.antiviruslab.com ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net --- Eingehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 www.zoologie-online.de Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg --- Ausgehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003
RE: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
erm, nein, am besten du machst das mit dem Query Analyzer und nicht mit dem Enterprise Manager. Folgendes Skript sollte helfen: USE meineDatenbank GO EXEC sp_dboption 'meineDatenbank', 'autoshrink', true GO EXEC sp_dboption 'meineDatenbank', 'trunc.log on chkpt.', true GO BACKUP LOG meineDatenbank WITH TRUNCATE_ONLY GO EXEC sp_configure 'fill factor', 0 GO ALTER DATABASE RECOVERY SIMPLE GO Sorry für Tippfehler, das hab ich grad so aus dem Kopf runtergetippert... lG Peter > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Berner > Sent: Saturday, January 03, 2004 3:57 PM > To: [EMAIL PROTECTED] > Subject: RE: Whidbey (WAS: RE: [Framework.net] Re: > [Framework.net] > System.ComponentModel.Design.Serialization.DesignerSerializerA > ttribute) > > 'muss dich jetzt doch nochmal löchern: > > ich gehe im Enterprise Manager auf Verwaltung/Sicherung/Neues > Sicherungsmedium und dann? > > > > At 15:44 03.01.2004 +0100, you wrote: > > > > 194MB!!! > > > > > > Wie kann man sich das denn erklären? > > > Hast du da eine Idee? > > > > > > Viele Grüße > > > Lars > > > >Ja, typischer Fehler vieler SQL Admins: Logfile steht auf > unrestricted > >growth und du hast full recovery eingestellt. > >Ist beides unnötig. Mach mal ein BACKUP LOG logname TRUNCATE > ONLY damit du > >das riesen file los wirst und stell dann das logfile neu ein > mit anfang 2MB > >und Maximal 8MB das reicht voll... > > > >als nextes solltest du das Recovery Model der Datenbank auf > Simple stellen. > > > >Und danach deinen Test wiederholen um sinnvolle Werte zu > kriegen. Damit der > >Test auch Sinn macht: beim Löschen des Tabelleninhaltes > TRUNCATE TABLE > >verwenden statt DELETE, und nach dem befüllen unbedingt > entsprechend den > >Index defragmentieren und den FillFactor auf 0 stellen. > > > >Das sind alles Werte die für Spacetest sinn machen. Wenn du einen > >performance Test haben willst müßte man ein bisserl anders arbeiten. > > > >liebe Grüße > >Peter > > > >___ > >Framework.net mailing list > >[EMAIL PROTECTED] > >http://www.glengamoi.com/mailman/listinfo/framework.net > > > > > >--- > >Eingehende Mail ist zertifiziert virenfrei. > >Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). > >Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 > > > www.zoologie-online.de > > Lars Berner > Stormcrow-Software > Postfach: 110123 > 69071 Heidelberg > > Virus checked by G DATA AntiVirusKit Version: AVK 11.0.452 from 22.10.2002 Virus news: www.antiviruslab.com ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net
RE: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
Da ich hier mit einer MSDE auf meinem lokalen Rechner zugange bin und momentan bloss diese Testversion dieser SQL-Server-Tools habe, lässt er mich im Enterprise Manager nicht an die Eigenschaften der Datenbank heran. Ich glaube man kann da unter Optionen den Wiederherstellungsmodus verstellen, oder? Modell/Model auf Einfach/Simpel.. Da komme ich aber hier bei der MSDE irgendwie nicht hin. Es heißt immer "Fehler 1038: Leere Objekte oder Spaltennamen können nicht verwendet werden. Verwenden Sie bei Bedarf ein Leerzeichen." Ist die Frage, ob/wie man das bei der MSDE machen kann.. Viele Grüße Lars At 15:57 03.01.2004 +0100, you wrote: 'muss dich jetzt doch nochmal löchern: ich gehe im Enterprise Manager auf Verwaltung/Sicherung/Neues Sicherungsmedium und dann? At 15:44 03.01.2004 +0100, you wrote: > 194MB!!! > > Wie kann man sich das denn erklären? > Hast du da eine Idee? > > Viele Grüße > Lars Ja, typischer Fehler vieler SQL Admins: Logfile steht auf unrestricted growth und du hast full recovery eingestellt. Ist beides unnötig. Mach mal ein BACKUP LOG logname TRUNCATE ONLY damit du das riesen file los wirst und stell dann das logfile neu ein mit anfang 2MB und Maximal 8MB das reicht voll... als nextes solltest du das Recovery Model der Datenbank auf Simple stellen. Und danach deinen Test wiederholen um sinnvolle Werte zu kriegen. Damit der Test auch Sinn macht: beim Löschen des Tabelleninhaltes TRUNCATE TABLE verwenden statt DELETE, und nach dem befüllen unbedingt entsprechend den Index defragmentieren und den FillFactor auf 0 stellen. Das sind alles Werte die für Spacetest sinn machen. Wenn du einen performance Test haben willst müßte man ein bisserl anders arbeiten. liebe Grüße Peter ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net --- Eingehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 www.zoologie-online.de Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg --- Ausgehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 www.zoologie-online.de Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg --- Ausgehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003
RE: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
'muss dich jetzt doch nochmal löchern: ich gehe im Enterprise Manager auf Verwaltung/Sicherung/Neues Sicherungsmedium und dann? At 15:44 03.01.2004 +0100, you wrote: > 194MB!!! > > Wie kann man sich das denn erklären? > Hast du da eine Idee? > > Viele Grüße > Lars Ja, typischer Fehler vieler SQL Admins: Logfile steht auf unrestricted growth und du hast full recovery eingestellt. Ist beides unnötig. Mach mal ein BACKUP LOG logname TRUNCATE ONLY damit du das riesen file los wirst und stell dann das logfile neu ein mit anfang 2MB und Maximal 8MB das reicht voll... als nextes solltest du das Recovery Model der Datenbank auf Simple stellen. Und danach deinen Test wiederholen um sinnvolle Werte zu kriegen. Damit der Test auch Sinn macht: beim Löschen des Tabelleninhaltes TRUNCATE TABLE verwenden statt DELETE, und nach dem befüllen unbedingt entsprechend den Index defragmentieren und den FillFactor auf 0 stellen. Das sind alles Werte die für Spacetest sinn machen. Wenn du einen performance Test haben willst müßte man ein bisserl anders arbeiten. liebe Grüße Peter ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net --- Eingehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 www.zoologie-online.de Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg --- Ausgehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003
RE: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
> 194MB!!! > > Wie kann man sich das denn erklären? > Hast du da eine Idee? > > Viele Grüße > Lars Ja, typischer Fehler vieler SQL Admins: Logfile steht auf unrestricted growth und du hast full recovery eingestellt. Ist beides unnötig. Mach mal ein BACKUP LOG logname TRUNCATE ONLY damit du das riesen file los wirst und stell dann das logfile neu ein mit anfang 2MB und Maximal 8MB das reicht voll... als nextes solltest du das Recovery Model der Datenbank auf Simple stellen. Und danach deinen Test wiederholen um sinnvolle Werte zu kriegen. Damit der Test auch Sinn macht: beim Löschen des Tabelleninhaltes TRUNCATE TABLE verwenden statt DELETE, und nach dem befüllen unbedingt entsprechend den Index defragmentieren und den FillFactor auf 0 stellen. Das sind alles Werte die für Spacetest sinn machen. Wenn du einen performance Test haben willst müßte man ein bisserl anders arbeiten. liebe Grüße Peter ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net
Re: Whidbey (WAS: RE: [Framework.net] Re: [Framework.net] System.ComponentModel.Design.Serialization.DesignerSerializerAttribute)
..das mit Yukon wird sicher vieles verändern, zumal man nicht mehr auf das T-SQL beschränkt ist sondern mit der .NET Klassenbibliothek arbeiten kann und C# und VB.NET coden kann. wo wir gerade bei DBs sind: Bin hier gerade am Probieren mit MS SQL Server und habe mir - zum Test - eine DB angelegt, die eine Tabelle mit einem Int-Wert und einem Unique Identifier (für Primärschlüssel) hat. Was ich probieren wollte ist den Platzbedarf für diese Uniqueidentifier, die ja immerhin 16Byte pro wert beanspruchen.. So komme ich, wenn ich die Spalte vomTyp Int mit dem Wert 5 fülle und den Uniqueidentifier automatisch von der DB generieren lasse, auf eine Größe von 23MB bei der mdf-Datei, wenn ich hier insgesamt 550 000 Rows generiere. Den Inhalt habe ich dann wieder gelöscht und die Spalte von Uniqueidentifier auf BIGINT mit Autoincreament gestellt,um zu sehen, wieviel das ausmacht.. Jetzt kommt der Hammer, den ich nicht verstehe: die dazugehörige .LOG datei umfasst jetzt 194MB!!! Wie kann man sich das denn erklären? Hast du da eine Idee? Viele Grüße Lars At 15:21 03.01.2004 +0100, you wrote: Hallo Lars, Nein, entwickeln macht damit absolut keinen Sinn. Ich schau mir das blos an damit ich in naher Zukunft auch mal ein paar Talks dazu halten kann. Und natürlich check ich von Zeit zu Zeit ob meine Components auch unter Whidbey sauber laufen und richtig compilen... Für mich is whidbey derzeit hauptsächlich wegen Yukon wichtig. Was es da an neuen Klassen gibt is echt faszinierend. liebe Grüße Peter > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Berner > Sent: Saturday, January 03, 2004 3:17 PM > To: [EMAIL PROTECTED] > Subject: RE: [Framework.net] Re: [Framework.net] > System.ComponentModel.Design.Serialization.DesignerSerializerAttribute > > Hi Peter, > > macht das Entwickeln damit schon Sinn? > Ich denke, wenn ich mit einer vernünftigen Beta damit loslege, bin ich > noch früh genug damit, findest du nicht auch? ;-) > > Viele Grüße > Lars > > > At 03:53 03.01.2004 +0100, you wrote: > > >uppsss, ich hab dein mail vorher falsch > verstanden/beantwortet. dachte > >zuerst, dass du dich auf mein generisches pluginsystem > beziehst. Aber > >falls du whidbey, yukon, longhorn meinst: ja, ich hab die > PDC TechPreview. > > > >lG > >Peter > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of > Lars Berner > > > Sent: Friday, January 02, 2004 11:00 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [Framework.net] Re: [Framework.net] > > > > System.ComponentModel.Design.Serialization.DesignerSerializerAttribu > > > te > > > > > > Hast du da schon eine Alpha/Beta zur verfügung ?? > > > > > > Viele Grüße > > > Lars > > > > > > > > > At 23:35 01.01.2004 +0100, you wrote: > > > >Mittlerweile hab ich das hinbekommen. Irgendwie hab ich aus > > > versehn die > > > >dll von whidbey erwischt *upppsss* > > > > > > > > > www.zoologie-online.de > > > > > > Lars Berner > > > Stormcrow-Software > > > Postfach: 110123 > > > 69071 Heidelberg > > > > > > > > > >___ > >Framework.net mailing list > >[EMAIL PROTECTED] > >http://www.glengamoi.com/mailman/listinfo/framework.net > > > > > >--- > >Eingehende Mail ist zertifiziert virenfrei. > >Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). > >Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 > > > www.zoologie-online.de > > Lars Berner > Stormcrow-Software > Postfach: 110123 > 69071 Heidelberg > > ___ Framework.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/framework.net --- Eingehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003 www.zoologie-online.de Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg --- Ausgehende Mail ist zertifiziert virenfrei. Überprüft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.556 / Virendatenbank: 348 - Erstellungsdatum: 26.12.2003
