Performance Monitoring in Server Core in Windows Server 2008

Performance Monitoring

The Reliability and Performance Monitor (RPM) console is not available on Server Core, however, the Performance Logs and Alerts service and the underlying performance subsystem is the same as a full installation of Windows Server 2008. Performance Monitoring of a Server Core server can be accomplished using the following methods:

■        Remotely using Performance Monitor on a full installation of Windows Server 2008 or Windows Vista

■        Locally on Server Core using the following command line performance monitoring tools:

Logman.exe

Logman.exe can be used to perform the following tasks:

■        Locally and remotely manage performance counter and event trace log collections.

■        Configure a data collector set on one computer and then copy that configuration to multiple computers from a central location.

■        Query currently-running logs and event traces.

Command Syntax

logman [create|query|start|stop|delete|update|import|export][options]

The following table describes logman.exe command line parameters:

Table 13: LOGMAN Command Parameters

Parameter	Description
Verbs
create	Create a new data collector.
query	Query data collector properties by name.
start	Start an existing data collector and set the begin time to manual.
stop	Stop an existing data collector and set the end time to manual.
delete	Delete an existing data collector.
update	Update an existing data collector's properties.
import	Import a data collector set from an XML file.
export	Export a data collector set to an XML file.
Options
-?	Displays context sensitive help.
-s	Perform the command on specified remote system.
-config	Settings file containing command options.
-ets	Send commands to Event Trace Sessions without saving or scheduling.

A common scenario for using logman.exe on Server Core is to create a Data Collector Set using Performance Monitor on a full installation of Windows Server 2008, or Windows Vista, and export the Data Collector Set configuration as an XML template. Then, use logman.exe to import and start the Data Collector Set on a Server Core server. After exporting the Data Collector Set XML template file, the following command can be used to import the XML template using logman.exe:

logman import –n <name> -xml <filename>

where:
<name> = desired name for target Data Collector Set
<filename> = name of XML template to import

To start the Performance Monitor Data Collector Set after inporting the XML template, type the following command at the command prompt:

logman start <name>

where:
<name> =  name of Data Collector Set to start

Tip All of the configured Data Collector Sets may be listed using logman query.

The Performance Monitor log file will be created in the following folder, by default:

%systemdrive%\PerfLogs

Relog.exe

Relog can be used to create new performance logs from data in existing performance logs by changing the sampling rate and/or converting the file format. Supports all performance log formats, including Windows NT 4.0 compressed logs.

Command Syntax

relog <filename [filename ...] [options]

The following table describes Relog command line parameters.

Table 14: RELOG Command Parameters

Parameter	Description
<filename [filename ...]	Required: Performance file to relog.
Options
-?	Displays context sensitive help.
-a	Append output to the existing binary file.
-c <path [path ...]>	Counters to filter from the input log.
-cf <filename>	File listing performance counters to filter from the input log. Default is all counters in the original log file.
-f <CSV|TSV|BIN|SQL>	Output file format.
-t <value>	Only write every nth record into the output file. Default is to write every record.
-o	Output file path or SQL database.
-b <M/d/yyyy h:mm:ss[AM|PM]	Begin time for the first record to write into the output file.
-e <M/d/yyyy h:mm:ss[AM|PM]	End time for the last record to write into the output file.
-config <filename>	Settings file containing command options.
-q	List performance counters in the input file.
-y	Answer yes to all questions without prompting.

Typeperf.exe

Typeperf.exe can be used to perform the following tasks:

■        Write performance data to the command window or to a supported log file format (csv | tsv | bin | sql).

■        Display all of the counters that are currently available on a particular local or remote computer.

Command Syntax

typeperf { <counter [counter ...]>

                                | -cf <filename>

                                | -q [object]

                                | -qx [object]

                                } [options]

The following table describes typeperf command line parameters

Typeperf.exe supports the following commands:

Table 15: Typeperf Command Parameters

Parameter	Description
<counter [counter ...]>	Required: Performance counters to monitor. Note The counter parameter(s) specify the full name of a performance counter in\\>\<object>(<instance>)\<counter> format. Example: \\Server1\Processor(0)\% User Time
Options
-f <CSV|TSV|BIN|SQL>	Output file format. Default is CSV.
-cf <filename>	File containing performance counters to monitor, one per line.
-si <[[hh:]mm:]ss>	Time between samples. Default is 1 second.
-o <filename>	Path of output file or SQL database. Default is STDOUT.
-q [object]	List installed counters (no instances). To list counters for one object, include the object name, such as Processor.
-qx [object]	List installed counters with instances. To list counters for one object, include the object name, such as Processor.
-sc <samples>	Number of samples to collect. Default is to sample until CTRL+C.
-config <filename>	Settings file containing command options.
-s <computer_name>	Server to monitor if no server is specified in the counter path.
-y	Answer yes to all questions without prompting.
-?	Displays context sensitive help.

Reference:-http://blogs.technet.com/perfguru/archive/2008/03/10/performance-monitoring-in-server-core-in-windows-server-2008.aspx

Flat file database

A flat file database describes any of various means to encode a database model (most commonly a table) as a plain text file.

A simple diagram depicting conversion of a CSV-format flat file database table into a relational databasetable.

Flat files

A flat file is a plain text (or mixed text and binary) file which usually contains one record per line^[1] or 'physical' record (example on discor tape). Within such a record, the single fields can be separated by delimiters, e.g. commas, or have a fixed length. In the latter case, padding may be needed to achieve this length. Extra formatting may be needed to avoid delimiter collision. There are no structural relationships between the records.

Typical examples of flat files are /etc/passwd and /etc/group on Unix-like operating systems. Another example of a flat file is a name-and-address list with the fields Name, Address, and Phone Number.

Implementation

It is possible to write out by hand, on a sheet of paper, a list of names, addresses, and phone numbers; this is a flat file database. This can also be done with any typewriter or word processor. Many pieces of computer software are designed to implement flat file databases.

[edit]Historical implementations

The first uses of computing machines were implementations of simple databases. Herman Hollerith conceived the idea that any resident of the United States could be represented by a string of exactly 80 digits and letters—name, age, and so forth, padded as needed with spaces to make everyone's name the same length, so the database fields would "line up" properly. He sold his concept, his machines, and the punched cards which both recorded and stored this data to the US Census Bureau; thus, the Census of 1890 was the first ever computerized database—consisting, in essence, of thousands of boxes full of punched cards.

Throughout the years following World War II, primitive electronic computers were run by governments and corporations; these were very often used to implement flat file databases, the most typical of which were accounting functions, such as payroll. Very quickly, though, these wealthy customers demanded more from their extremely expensive machines, which led to early relational databases. Amusingly enough, these early applications continued to use Hollerith cards, slightly modified from the original design; Hollerith's enterprise grew into computer giantIBM, which dominated the market of the time. The rigidity of the fixed-length field, 80-column punch card driven database made the early computer a target of attack^{[clarification needed]}, and a mystery to the common man.

In the 1980s, configurable flat-file database computer applications were popular on DOS and the Macintosh. These programs were designed to make it easy for individuals to design and use their own databases, and were almost on par with word processors and spreadsheets in popularity. Examples of flat-file database products were early versions of FileMaker and theshareware PC-File. Some of these offered limited relational capabilities, allowing some data to be shared between files.

Contemporary implementations

Faircom's C-tree is an example of a modern enterprise-level solution, but aside from that, there are very few programs available today that would allow a novice to create and use a general-purpose flat file database. This functionality is implemented in Microsoft Works (available only for some versions of Windows) and AppleWorks, sometimes named ClarisWorks (available for both Macintosh and Windows platforms). Over time, products like Borland's Paradox, and Microsoft's Access started offering some relational capabilities, as well as built-in programming languages. Database Management Systems (DBMS) like MySQL or Oracle generally require programmers to build applications.

Flat file databases are still used internally by many computer applications to store configuration data. Many applications allow users to store and retrieve their own information from flat files using a pre-defined set of fields. Examples are programs to manage collections of books or appointments. Some small "contact" (name-and-address) database implementations essentially use flat files.

XML is now a popular format for storing data in plain text files, but as XML allows very complex nested data structures to be represented and contains the definition of the data, it would be incorrect to describe this type of database as conforming to the flat-file model.

Terms

"Flat file database" may be defined very narrowly, or more broadly. The narrower interpretation is correct in database theory; the broader covers the term as generally used.

Strictly, a flat file database should consist of nothing but data and, if records vary in length, delimiters. More broadly, the term refers to any database which exists in a single file in the form of rows and columns, with no relationships or links between records and fields except the table structure.

Terms used to describe different aspects of a database and its tools differ from one implementation to the next, but the concepts remain the same. FileMaker uses the term "Find", while MySQL uses the term "Query"; but the concept is the same. FileMaker "files" are equivalent to MySQL "tables", and so forth. To avoid confusing the reader, one consistent set of terms is used throughout this article.

However, the basic terms "record" and "field" are used in nearly every database implementation.

[edit]Example database

The following example illustrates the basic elements of a flat-file database. The data arrangement consists of a series of columns and rows organized into a tabular format. This specific example uses only one table.

The columns include: name (a person's name, second column); team (the name of an athletic team supported by the person, third column); and a numeric unique ID, (used to uniquely identify records, first column).

Here is an example textual representation of the described data:

id    name    team 1     Amy     Blues 2     Bob     Reds 3     Chuck   Blues 4     Dick    Blues 5     Ethel   Reds 6     Fred    Blues 7     Gilly   Blues 8     Hank    Reds 

This type of data representation is quite standard for a flat-file database, although there are some additional considerations that are not readily apparent from the text:

• Data types: each column in a database table such as the one above is ordinarily restricted to a specific data type. Such restrictions are usually established by convention, but not formally indicated unless the data is transferred to a relational database system.
• Separated columns: In the above example, individual columns are separated using whitespace characters. This is also called indentation or "fixed-width" data formatting. Another common convention is to separate columns using one or more delimiter characters. There are many different conventions for depicting data such as that above in text. (See e.g.,Comma-separated values, Delimiter-separated values, Markup language, Programming language). Using delimiters incurs some overhead in locating them every time they are processed (unlike fixed-width formatting) which may have some performance implications. However, use of character delimiters (especially commas) is also a crude form of data compression which may assist overall performance by reducing data volumes - especially for data transmission purposes. Use of character delimiters which include a length component (Declarative notation) is comparatively rare but vastly reduces the overhead associated with locating the extent of each field.
• Relational algebra: Each row or record in the above table meets the standard definition of a tuple under relational algebra (the above example depicts a series of 3-tuples). Additionally, the first row specifies the field names that are associated with the values of each row.
• Database management system: Since the formal operations possible with a text file are usually more limited than desired. The text in the above example would ordinarily represent an intermediary state of the data prior to being transferred into a database management system.
  

Reference :- http://en.wikipedia.org/wiki/Flat_file_database