Collecting a profile in the background?

Collecting a profile in the background?

Post by cfl-r » Wed, 23 Oct 2002 20:56:53



I have a trace template that shows high CPU or Duration queries passing
through a
MSSQL 2000 server with many client databases on it.  Is it possible to keep
the trace running in the background so that the data is always written to a
table allowing clients to examine the data about their queries?  I could
keep a terminal window open with a workload compiling, but that's kind of
sloppy.

Thanks.

 
 
 

1. Architect Question: Creating profile and sub-profile

Here is a scenario...

An online data seller, McgrawHill Inc., sells science,
business, and philosopy data to Universities.  McgrawHill
would like to make a university profile for universities.
For example, if MIT subscribe for science and business
articles then their search screen will only display
science categories such as information technology,
computer engineering and business categories such as
economics, management, etc.

And, university would like to make the profile for
different teachers to what they can search. For example,
when computer science teachers log in then they will see
an option to search for information technology article
only.

The easiest solution would be creating a sql server views
for each university and creating views for each teacher
calling their university view. For example,

vMITUniversity:
select * from Article where ArticleType = 'Science'

vAlbertEinstien:
select * from vMITUniversity where ArticleSubType
= 'information technology'

Above sql-server view solution works well in terms of what
the university and their user can see. Especially, if MIT
every try to cut back their subscription to science only
then McGrawHill has to update only MIT view.  All teachers
view are inherited from MIT view so no need to change or
update their views.

However, the view solution is cumbersome when you have
1000 Universities and each University has 100
users/teachers. It would result in 1000+100,000 = 101,000
views.  I am not sure if the performance will slow as
number of views will increase.

Here is a question: I would like to know what is the
standard industry practise to solve this problems. Some
suggest holding university and user profile information in
2 profile tables and use store proc instead of views. Some
suggest creating different databases for different
university.

Any help or feed back would be appreciated.

2. sql services stopped....

3. SQL*Plus site profile/user profile on Solaris

4. Failback port settings

5. Collecting errors from ADO connection to SQL Server

6. updated utilities for PocketPC 2002

7. Collecting Resumes

8. getting result set from SP

9. Collecting informatin for billing purposes

10. HOW TO: Collect information from a datapump task and insert values to separate table

11. Collect data

12. Collecting data from fill-out/data entry forms

13. Collecting data from an ODBC conection