Monitoring SQL Server Error Message - Severity Level Messages

Hello,
Do SQL server error messages (severilty level messages 11-16 & 17-25),
both 2000 & 2005, get written to the Windows Application Log, as well
as, the SQL server error log? I mainly monitor the server externally
(Windows Event Logs) and would like to NOT have to configure a MAPI
client on SQL to receive the SQL server severity errors.
Thanks,
Dan
The ones that are written to the errorlog are also written to the eventlog.
However, whether an error is to be written to eventlog/errorlog depends on whether it is configured
to do so. In 2000, sysmessages table, check the dlevel column. In 2005, check sys.messages. In 2000,
you can specify whether an error is to be logged (using sp_altermessage), but not in 2005.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"danfoxley@.anon.postalias" <danfoxley@.gmail.com> wrote in message
news:1187251441.579647.169310@.i38g2000prf.googlegr oups.com...
> Hello,
> Do SQL server error messages (severilty level messages 11-16 & 17-25),
> both 2000 & 2005, get written to the Windows Application Log, as well
> as, the SQL server error log? I mainly monitor the server externally
> (Windows Event Logs) and would like to NOT have to configure a MAPI
> client on SQL to receive the SQL server severity errors.
> Thanks,
> Dan
>

Monitoring SQL Server Error Message - Severity Level Messages

Hello,
Do SQL server error messages (severilty level messages 11-16 & 17-25),
both 2000 & 2005, get written to the Windows Application Log, as well
as, the SQL server error log? I mainly monitor the server externally
(Windows Event Logs) and would like to NOT have to configure a MAPI
client on SQL to receive the SQL server severity errors.
Thanks,
DanThe ones that are written to the errorlog are also written to the eventlog.
However, whether an error is to be written to eventlog/errorlog depends on whether it is configured
to do so. In 2000, sysmessages table, check the dlevel column. In 2005, check sys.messages. In 2000,
you can specify whether an error is to be logged (using sp_altermessage), but not in 2005.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"danfoxley@.anon.postalias" <danfoxley@.gmail.com> wrote in message
news:1187251441.579647.169310@.i38g2000prf.googlegroups.com...
> Hello,
> Do SQL server error messages (severilty level messages 11-16 & 17-25),
> both 2000 & 2005, get written to the Windows Application Log, as well
> as, the SQL server error log? I mainly monitor the server externally
> (Windows Event Logs) and would like to NOT have to configure a MAPI
> client on SQL to receive the SQL server severity errors.
> Thanks,
> Dan
>

Monitoring SQL Server Error Message - Severity Level Messages

Hello,
Do SQL server error messages (severilty level messages 11-16 & 17-25),
both 2000 & 2005, get written to the Windows Application Log, as well
as, the SQL server error log? I mainly monitor the server externally
(Windows Event Logs) and would like to NOT have to configure a MAPI
client on SQL to receive the SQL server severity errors.
Thanks,
DanThe ones that are written to the errorlog are also written to the eventlog.
However, whether an error is to be written to eventlog/errorlog depends on w
hether it is configured
to do so. In 2000, sysmessages table, check the dlevel column. In 2005, chec
k sys.messages. In 2000,
you can specify whether an error is to be logged (using sp_altermessage), bu
t not in 2005.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"danfoxley@.anon.postalias" <danfoxley@.gmail.com> wrote in message
news:1187251441.579647.169310@.i38g2000prf.googlegroups.com...
> Hello,
> Do SQL server error messages (severilty level messages 11-16 & 17-25),
> both 2000 & 2005, get written to the Windows Application Log, as well
> as, the SQL server error log? I mainly monitor the server externally
> (Windows Event Logs) and would like to NOT have to configure a MAPI
> client on SQL to receive the SQL server severity errors.
> Thanks,
> Dan
>

Monitor network traffic per database

Is it possible to monitor incoming and outgoing network
traffic on a database level? I could only find counters
on server level.
Thanks in advance.
HolgerNot from any network monitor... about the best you can do is to use
profiler. You can see selects, etc and the number of rows returned...
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Holger" <holger.haeffelin@.arcworx.net> wrote in message
news:0cd801c3d52e$6122d330$a101280a@.phx.gbl...
> Is it possible to monitor incoming and outgoing network
> traffic on a database level? I could only find counters
> on server level.
> Thanks in advance.
> Holger|||Yes. All the performance counters are at a SQL Server level. Not at a
database specific level. The only thing that comes to my mind is wrt to the
IO operations that can be monitored if you can group filegroups of a
specific database into a single disk and monitor the Disk IO of the specific
disk. This is the max. I've seen implemented. But other parameters are can
be monitored using the profiler as Wayne said ...
--
HTH,
Vinod Kumar
MCSE, DBA, MCAD, MCSD
http://www.extremeexperts.com
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp
"Holger" <holger.haeffelin@.arcworx.net> wrote in message
news:0cd801c3d52e$6122d330$a101280a@.phx.gbl...
> Is it possible to monitor incoming and outgoing network
> traffic on a database level? I could only find counters
> on server level.
> Thanks in advance.
> Holger

Monitor DB Usage at Column Level

I'm looking for a tool that will compile historical usage information for a
specific SQL Server 2000 database down to the column-level. This is a
read-only database and I need to know how many times each column of each
table has been included in a query over a period of time. This is a
production database, so it has to be a tool that won't have a major impact on
performance.
Any suggestions?
Thanks,
Hari
Hari Seldon (HariSeldon@.discussions.microsoft.com) writes:
> I'm looking for a tool that will compile historical usage information
> for a specific SQL Server 2000 database down to the column-level. This
> is a read-only database and I need to know how many times each column of
> each table has been included in a query over a period of time. This is
> a production database, so it has to be a tool that won't have a major
> impact on performance.
You would have to run a server-side trace that captures the SP:StmtCompleted
and SQL:StmtCompleted events. Exactly what columns you should include
in the trace depends on your needs, but a minimum you would have to
include TextData. The trace should save data to a file.
The performance impact on such a query is not negligible, particularly if
users run many small queries. (If they main run long-running queries, the
number of events to track is much smaller.)
The easiest way to set up such a trace is to use Profiler, and then save
the trace as a script.
That was the easy part. Once you have the trace data, you need to analyse
it, one way or another. Unless you application generates command in a way
that makes things easy for you, for instance it always uses
tablename.columnname, this is a difficult task, and I don't know
of any tool that does this, thereby not said that it does not exist.
Presumably, a program would have to read the file, and parse each query to
determine which columns that are referred to in the query.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||"Erland Sommarskog" wrote:

> Hari Seldon (HariSeldon@.discussions.microsoft.com) writes:
> You would have to run a server-side trace that captures the SP:StmtCompleted
> and SQL:StmtCompleted events. Exactly what columns you should include
> in the trace depends on your needs, but a minimum you would have to
> include TextData. The trace should save data to a file.
> The performance impact on such a query is not negligible, particularly if
> users run many small queries. (If they main run long-running queries, the
> number of events to track is much smaller.)
> The easiest way to set up such a trace is to use Profiler, and then save
> the trace as a script.
> That was the easy part. Once you have the trace data, you need to analyse
> it, one way or another. Unless you application generates command in a way
> that makes things easy for you, for instance it always uses
> tablename.columnname, this is a difficult task, and I don't know
> of any tool that does this, thereby not said that it does not exist.
> Presumably, a program would have to read the file, and parse each query to
> determine which columns that are referred to in the query.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>
|||Thanks. I really appreciate the info. I had a feeling this wasn't going to
be easy.
Hari
"Erland Sommarskog" wrote:

> Hari Seldon (HariSeldon@.discussions.microsoft.com) writes:
> You would have to run a server-side trace that captures the SP:StmtCompleted
> and SQL:StmtCompleted events. Exactly what columns you should include
> in the trace depends on your needs, but a minimum you would have to
> include TextData. The trace should save data to a file.
> The performance impact on such a query is not negligible, particularly if
> users run many small queries. (If they main run long-running queries, the
> number of events to track is much smaller.)
> The easiest way to set up such a trace is to use Profiler, and then save
> the trace as a script.
> That was the easy part. Once you have the trace data, you need to analyse
> it, one way or another. Unless you application generates command in a way
> that makes things easy for you, for instance it always uses
> tablename.columnname, this is a difficult task, and I don't know
> of any tool that does this, thereby not said that it does not exist.
> Presumably, a program would have to read the file, and parse each query to
> determine which columns that are referred to in the query.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
>