Automating SQL Profiler

The powers at be have decided that they would like to automatically run

a trace on one of our analysis servers when it processes a cube in the

early hours of the morning. Now I have no problem creating a SQL

Profile to run and store the results in a database table for them, but

I have no idea how to automate it so that it runs everyday, any help

would be greatly appreciated. My apologises for posting this in forums

let's search in the internet with your subject.

you will find a lot of articles. this is one of them.
http://www.lazydba.com/sql/1__18318.html

Automating SQL Profiler

The powers at be have decided that they would like to automatically run

a trace on one of our analysis servers when it processes a cube in the

early hours of the morning. Now I have no problem creating a SQL

Profile to run and store the results in a database table for them, but

I have no idea how to automate it so that it runs everyday, any help

would be greatly appreciated. My apologises for posting this in forums

Option B - Not sure what information you want to capture from trace but if you are processing your cube using SSIS package you can capture log in database table at package level and cube level both. In cube level log there are many options you can select like sql, start, end time and lot more. This way when your SSIS package will run your database table will also get populated.

-Ashok

|||

SP2 is going to come out with little sample application ASTrace. This tiny sample installs as a service and knows how to subsribe to Analysis Services trace and output this trace into SQL Server table.

Drop me a line if you are in urgent need to solve this problem and cant wait for SP2 (which is pretty close).

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Autogrow problem

We are seeing an issue with the autogrow setting on some of our production
databases. Occasionally we will see a database fill up, processes trying to
write to the db will show page latch waits and the database will not grow for
up to five hours. The last time it occured, the database only needed to grow
400MB but it did not for hours. Once it did grow most of the writes which
had been waiting did not occur. Their is plenty of space on the disk and the
server was not at capacity. Any ideas?
Thank You.Autogrow is a necessary evil...you should be maintaining your data and log
file sizes based on the expected amount of transactions and altering them
during maintenance hours. Autogrow ought to be a failsafe only due to the
performance impact...
--
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:E6CD323D-2F34-42F6-8EF4-926D2FC69730@.microsoft.com...
> We are seeing an issue with the autogrow setting on some of our production
> databases. Occasionally we will see a database fill up, processes trying
> to
> write to the db will show page latch waits and the database will not grow
> for
> up to five hours. The last time it occured, the database only needed to
> grow
> 400MB but it did not for hours. Once it did grow most of the writes which
> had been waiting did not occur. Their is plenty of space on the disk and
> the
> server was not at capacity. Any ideas?
> Thank You.

Autogrow problem

We are seeing an issue with the autogrow setting on some of our production
databases. Occasionally we will see a database fill up, processes trying to
write to the db will show page latch waits and the database will not grow for
up to five hours. The last time it occured, the database only needed to grow
400MB but it did not for hours. Once it did grow most of the writes which
had been waiting did not occur. Their is plenty of space on the disk and the
server was not at capacity. Any ideas?
Thank You.
Autogrow is a necessary evil...you should be maintaining your data and log
file sizes based on the expected amount of transactions and altering them
during maintenance hours. Autogrow ought to be a failsafe only due to the
performance impact...
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:E6CD323D-2F34-42F6-8EF4-926D2FC69730@.microsoft.com...
> We are seeing an issue with the autogrow setting on some of our production
> databases. Occasionally we will see a database fill up, processes trying
> to
> write to the db will show page latch waits and the database will not grow
> for
> up to five hours. The last time it occured, the database only needed to
> grow
> 400MB but it did not for hours. Once it did grow most of the writes which
> had been waiting did not occur. Their is plenty of space on the disk and
> the
> server was not at capacity. Any ideas?
> Thank You.

Autogrow problem

We are seeing an issue with the autogrow setting on some of our production
databases. Occasionally we will see a database fill up, processes trying to
write to the db will show page latch waits and the database will not grow fo
r
up to five hours. The last time it occured, the database only needed to gro
w
400MB but it did not for hours. Once it did grow most of the writes which
had been waiting did not occur. Their is plenty of space on the disk and th
e
server was not at capacity. Any ideas?
Thank You.Autogrow is a necessary evil...you should be maintaining your data and log
file sizes based on the expected amount of transactions and altering them
during maintenance hours. Autogrow ought to be a failsafe only due to the
performance impact...
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
www.DallasDBAs.com/forum - new DB forum for Dallas/Ft. Worth area DBAs.
www.experts-exchange.com - experts compete for points to answer your
questions
"Len Gustafson" <LenGustafson@.discussions.microsoft.com> wrote in message
news:E6CD323D-2F34-42F6-8EF4-926D2FC69730@.microsoft.com...
> We are seeing an issue with the autogrow setting on some of our production
> databases. Occasionally we will see a database fill up, processes trying
> to
> write to the db will show page latch waits and the database will not grow
> for
> up to five hours. The last time it occured, the database only needed to
> grow
> 400MB but it did not for hours. Once it did grow most of the writes which
> had been waiting did not occur. Their is plenty of space on the disk and
> the
> server was not at capacity. Any ideas?
> Thank You.

Auto increment after select?

I have two processes will continue to get the number from a table. After eac
h
get, the number should increment by 1, and the two processes need to be
getting a unique number. Is it possible to avoid the two processes get the
same number?Use locking mechansims to ensure that only one process gets to update the
count at any one time. For example, you can do an UPDLOCK on the table.
--
HTH,
SriSamp
Email: srisamp@.gmail.com
Blog: http://blogs.sqlxml.org/srinivassampath
URL: http://www32.brinkster.com/srisamp
"BntConan" <BntConan@.discussions.microsoft.com> wrote in message
news:0CB33A5A-3B3A-4DC6-BCCA-BED54594F42C@.microsoft.com...
>I have two processes will continue to get the number from a table. After
>each
> get, the number should increment by 1, and the two processes need to be
> getting a unique number. Is it possible to avoid the two processes get the
> same number?
>|||try this
declare @.Curr_Num int
Update Tbl set @.Curr_Num = CurrValue, CurrValue = Currvalue + 1
where < Condition >
select @.Curr_Num
tbl is the table from which u have to select the value.
and CurrValue holds the current value to be returned.
Tx