You basically created an alert that will get fired when the log space used percent is above 25%. That's pretty low, in my opinion.
Please let me know what action should I take so that I did not get this alert again Hard drive where transaction log get saved have enough space.
If what I'm understanding from you is correct, you're saying that the volume your transaction log sits on has plenty of space, and you think you may be getting false alerts? If that's correct, this perfmon counter isn't looking at that at all. It could be a 2 GB log file, living on a 500 GB volume. Even if that 500 GB volume has 400 GB of free space, if your 2 GB log file has 500+ MB space used you'll get that alert. Volume free space and database file free space are two different things.
You need to determine what you care about to be alerted on. It's a great strategy to alert on log file space used if it is getting high (in my opinion, the upper bounds would be 70% - 80%, but you will need to tailor that to your environment), but I think you may be confused with the above two points.
If that hasn't answered your question, please clarify either through comments here or editing your own question.
Edit after your edit
You need to see what your log space used percent is. By your alert, if it is greater than 25%, then you should be alerted. You can find that out a couple of ways.
The quickest is to run the following:
dbcc sqlperf(logspace);
That will give you a rundown of all log space used for every database. If you want to break that down for a particular database (for whatever reason) it could be accomplished this way:
use YourDatabase;
go
;with file_cte as
(
select
name,
size,
fileproperty(name, 'SpaceUsed') as space_used
from sys.database_files
where type_desc = 'log'
)
select
name,
size,
space_used,
convert(decimal(5, 2), space_used * 1.0 / size * 100) as space_used_percent
from file_cte;
The reason why you didn't get alerted after that is simple: Because your log space used didn't breach 25%. That could have been through log reuse due to a transaction log backup, or maybe somebody grew the file making that 25% space used a larger number. As for tempdb's database file sizes, that shouldn't affect when you get alerted, unless you are being alerted specifically for tempdb log file space used (in your question it says "my database name" so I'm assuming you're not alerting off of tempdb with this alert).
Operating system error 2 is a standard Windows operating system error--file not found. Check the permissions on the folder and make sure that the account that owns the agent job has access to the folder and is able to traverse the path to the folder where the backup is trying to write.
Unfortunately, this is a Windows error message and not a SQL error. I found something on Microsoft Connect (related to restore, not backups) where they said they were not able to reproduce the problem and confirmed that this is an OS, not a SQL Server, error message.
Best Answer
There's basically 4 things involved with backup speed:
Reading from the data files - you can test this by doing a backup to NUL:, as in this example, which won't break your log-backup chain for full recovery model databases:
Compressing the data - watch CPU pressure during the backup.
Third party backup products like Quest LiteSpeed, Idera SQLsafe, and Red Gate SQL Backup (disclaimer: I'm independent, but I've worked with all of those companies in the past) have wizards that will test each component of that, and then tell you where the bottleneck is. If you want to find it yourself, you're going to have to test each of those components, and then find the weakest link in the chain (the lowest throughput).
For example, if other SQL Servers are writing to the same target location, they may have suddenly had an increase of data or added more servers, thereby slowing down the target.