Avast Antivirus causing SQL Server 2005 not to start up

I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
developer PC. I installed SQL Server 2005 SP2 last week and installed
Avast Antivirus this week. What I noticed was that after my reboot, I
could not get SQL Server to start. In the Surface Area Configuration,
I was getting error messages in regards to me not having permission to
start the service.
So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
Alas, SQL Server 2005 was starting up again!
I use AVG Antivirus (free of course), and was wondering if anybody
else out there has had similar problems? Is it just Avast?
Thanks.
"tofu.captain" <tofu.captain@.gmail.com> wrote in message
news:1176693441.180857.3870@.w1g2000hsg.googlegroup s.com...
>I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
Generally suggest not running an AV on a SQL Server. At the very least
suggest telling it to not scan the databases.

> Thanks.
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hi
"tofu.captain" wrote:

> I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
> Thanks.
>
As this is a developer PC you probably do want to install an antivirus
program, but as Greg says do not scan the database files as SQL Server will
require exclusive access to these files. I would expect user databases to be
marked as suspect if the scan was occurring during start up, but SQL Server
may still start therefore the error message seems slightly spurious. Have you
checked the SQL Server log and the event log for any additional information?
John

Avast Antivirus causing SQL Server 2005 not to start up

I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
developer PC. I installed SQL Server 2005 SP2 last week and installed
Avast Antivirus this week. What I noticed was that after my reboot, I
could not get SQL Server to start. In the Surface Area Configuration,
I was getting error messages in regards to me not having permission to
start the service.
So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
Alas, SQL Server 2005 was starting up again!
I use AVG Antivirus (free of course), and was wondering if anybody
else out there has had similar problems? Is it just Avast?
Thanks."tofu.captain" <tofu.captain@.gmail.com> wrote in message
news:1176693441.180857.3870@.w1g2000hsg.googlegroups.com...
>I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
Generally suggest not running an AV on a SQL Server. At the very least
suggest telling it to not scan the databases.

> Thanks.
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hi
"tofu.captain" wrote:

> I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
> Thanks.
>
As this is a developer PC you probably do want to install an antivirus
program, but as Greg says do not scan the database files as SQL Server will
require exclusive access to these files. I would expect user databases to be
marked as suspect if the scan was occurring during start up, but SQL Server
may still start therefore the error message seems slightly spurious. Have yo
u
checked the SQL Server log and the event log for any additional information?
John

Avast Antivirus causing SQL Server 2005 not to start up

I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
developer PC. I installed SQL Server 2005 SP2 last week and installed
Avast Antivirus this week. What I noticed was that after my reboot, I
could not get SQL Server to start. In the Surface Area Configuration,
I was getting error messages in regards to me not having permission to
start the service.
So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
Alas, SQL Server 2005 was starting up again!
I use AVG Antivirus (free of course), and was wondering if anybody
else out there has had similar problems? Is it just Avast?
Thanks."tofu.captain" <tofu.captain@.gmail.com> wrote in message
news:1176693441.180857.3870@.w1g2000hsg.googlegroups.com...
>I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
Generally suggest not running an AV on a SQL Server. At the very least
suggest telling it to not scan the databases.
> Thanks.
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hi
"tofu.captain" wrote:
> I have SQL Server 2005 and Visual Studio .NET 2005 installed on my
> developer PC. I installed SQL Server 2005 SP2 last week and installed
> Avast Antivirus this week. What I noticed was that after my reboot, I
> could not get SQL Server to start. In the Surface Area Configuration,
> I was getting error messages in regards to me not having permission to
> start the service.
> So I uninstalled Avast Antivirus (Home Edition btw), and rebooted.
> Alas, SQL Server 2005 was starting up again!
> I use AVG Antivirus (free of course), and was wondering if anybody
> else out there has had similar problems? Is it just Avast?
> Thanks.
>
As this is a developer PC you probably do want to install an antivirus
program, but as Greg says do not scan the database files as SQL Server will
require exclusive access to these files. I would expect user databases to be
marked as suspect if the scan was occurring during start up, but SQL Server
may still start therefore the error message seems slightly spurious. Have you
checked the SQL Server log and the event log for any additional information?
John

Autonumbering causing deadlocks.

Gents,

I have come into a system that uses a secondary table to generate (for
want of a better word) Identities.

eg

create table myidents
( name sysname not null, ident int not null)

create procedure getnextident @.table sysname, @.ident int output
as
begin
if not exists (select top 1 1 from myidents where name = @.table)
insert into myidents values (@.table, 0)

update myidents
set @.ident = ident = ident + 1
where name = @.table
end

now, (ignoring for now the use of reserved words) the problem is that
this is called frequently, from other procedures. Trouble is that the
calling procedures call it from within a transaction. We now have a
wickedly hot spot on this table, with frequent deadlocks.

Is there any relatively quick fix for this? Some locking hints or
whatever.

Or do we need to go and recode, moving this kind of thing outside the
transaction (which are all rather too long for my liking), and even
cosidering using identity columns as a replacement?

ThanksIMHO, IDENTITY would be the best approach with the current design. You
might also consider using natural keys instead of surrogate key values.

If your actual myident table has no primary key on name, this will
contribute to blocking/deadlocking. Unless your application always acquires
values in the same sequence, you will be vulnerable to deadlocks unless you
specify a TABLOCKX hint. This is obviously bad for concurrency (especially
for long-running transactions) and should be avoided if possible.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"WangKhar" <Wangkhar@.yahoo.com> wrote in message
news:bb269444.0401220321.38788fa2@.posting.google.c om...
> Gents,
> I have come into a system that uses a secondary table to generate (for
> want of a better word) Identities.
> eg
> create table myidents
> ( name sysname not null, ident int not null)
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.
> Or do we need to go and recode, moving this kind of thing outside the
> transaction (which are all rather too long for my liking), and even
> cosidering using identity columns as a replacement?
> Thanks|||You could try this:

if not exists (select top 1 1 from myidents ROWLOCK, UPDLOCK where name =
@.table)

Hope it will help.

Igor

"WangKhar" <Wangkhar@.yahoo.com> wrote in message
news:bb269444.0401220321.38788fa2@.posting.google.c om...
> Gents,
> I have come into a system that uses a secondary table to generate (for
> want of a better word) Identities.
> eg
> create table myidents
> ( name sysname not null, ident int not null)
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.
> Or do we need to go and recode, moving this kind of thing outside the
> transaction (which are all rather too long for my liking), and even
> cosidering using identity columns as a replacement?
> Thanks|||WangKhar (Wangkhar@.yahoo.com) writes:
> create procedure getnextident @.table sysname, @.ident int output
> as
> begin
> if not exists (select top 1 1 from myidents where name = @.table)
> insert into myidents values (@.table, 0)
> update myidents
> set @.ident = ident = ident + 1
> where name = @.table
> end
> now, (ignoring for now the use of reserved words) the problem is that
> this is called frequently, from other procedures. Trouble is that the
> calling procedures call it from within a transaction. We now have a
> wickedly hot spot on this table, with frequent deadlocks.
> Is there any relatively quick fix for this? Some locking hints or
> whatever.

Deadlocks can usually be avoided by:

BEGIN TRANSACTION

SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
UPDATE tbl SET ident = @.ident WHERE name = @.table

COMMIT TRANSACTION

However, if you have more work in the transaction, you will have lot of
blocking and not much concurrency in the system. And if you in some
procedures perform work before you come here, they might be blocking
other processes that aleady have an ident, and now wil block the other
prcoess.

The above is only really meaningful if you have busienss rules that
require consecutive series. Else you should move out the ident-generation
out of the transaction or use IDENTITY instead.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks thats pretty much what I thought ...

See if I can convince people that we need to take this action :(

Erland Sommarskog <sommar@.algonet.se> wrote in message news:<Xns94794AA4B719Yazorman@.127.0.0.1>...
> WangKhar (Wangkhar@.yahoo.com) writes:
> > create procedure getnextident @.table sysname, @.ident int output
> > as
> > begin
> > if not exists (select top 1 1 from myidents where name = @.table)
> > insert into myidents values (@.table, 0)
> > update myidents
> > set @.ident = ident = ident + 1
> > where name = @.table
> > end
> > now, (ignoring for now the use of reserved words) the problem is that
> > this is called frequently, from other procedures. Trouble is that the
> > calling procedures call it from within a transaction. We now have a
> > wickedly hot spot on this table, with frequent deadlocks.
> > Is there any relatively quick fix for this? Some locking hints or
> > whatever.
> Deadlocks can usually be avoided by:
> BEGIN TRANSACTION
> SELECT @.ident = ident FROM tbl (UPDLOCK) WHERE name = @.table
> UPDATE tbl SET ident = @.ident WHERE name = @.table
> COMMIT TRANSACTION
> However, if you have more work in the transaction, you will have lot of
> blocking and not much concurrency in the system. And if you in some
> procedures perform work before you come here, they might be blocking
> other processes that aleady have an ident, and now wil block the other
> prcoess.
> The above is only really meaningful if you have busienss rules that
> require consecutive series. Else you should move out the ident-generation
> out of the transaction or use IDENTITY instead.