August 25, 2017 at 8:24 am
Is there any way to delete the xel file once I no longer need it without having to use something other than SSMS?
I won't have access to the server other than sql, and I don't want to keep creating new files every time that would last for the eternity.
August 25, 2017 at 10:50 am
Luis Cazares - Friday, August 25, 2017 8:24 AMIs there any way to delete the xel file once I no longer need it without having to use something other than SSMS?
I won't have access to the server other than sql, and I don't want to keep creating new files every time that would last for the eternity.
It depends. Do you have access to xp_cmdshell?
If so, just run that with a DEL filename through SSMS.
EXEC MASTER..XP_CMDSHELL 'del \\serverOrNas\path\filename'.
August 25, 2017 at 11:03 am
Brandie Tarvin - Friday, August 25, 2017 10:50 AMIt depends. Do you have access to xp_cmdshell?
I don't, they claim is a security measure. 🙁
August 25, 2017 at 11:04 am
Can you use Agent? You could run a PowerShell script to remove it that way.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 25, 2017 at 11:10 am
Actually, through SQL Server Agent, you can run a operating system command job step to delete the file using cmd window language (again Del filename).
Here's a link to an article I found.
August 25, 2017 at 11:24 am
Luis Cazares - Friday, August 25, 2017 11:03 AMBrandie Tarvin - Friday, August 25, 2017 10:50 AMIt depends. Do you have access to xp_cmdshell?
I don't, they claim is a security measure. 🙁
We have the same issue with our lock downs, but we also have code that enables it, does its thing, then disables it. It is the about the only way to do what needs to be done without creating an Agent Job to run a cmdshel job step and then drop the job.
August 25, 2017 at 11:28 am
There's always (in many environments) an "exceptions process" where one can request an exception for a specific use and then either do as Lynn suggests or leave it on but only let the DBAs know about it.
That requires a certain amount of monitoring and red tape, though.
August 25, 2017 at 11:52 am
So I'm trying to be evil here and see if there's a way to get around the xp_cmdshell thing using a SQLCMD query window in SSMS. Haven't found anything specific yet, but figured if anyone had done it, maybe they'll post the solution to your thread, Luiz.
August 25, 2017 at 11:56 am
Thank you for the good ideas. Sure, exceptions can be made and this will be used by DBAs (or selected developers), the problem is that we're development DBAs and the system DBAs won't give them that easily (and I don't blame them).
August 28, 2017 at 6:03 pm
Luis Cazares - Friday, August 25, 2017 11:56 AMThank you for the good ideas. Sure, exceptions can be made and this will be used by DBAs (or selected developers), the problem is that we're development DBAs and the system DBAs won't give them that easily (and I don't blame them).
It's the classial overspecialisation problem that leads to distrust of generlists and of specialists in a different area.. The area A experts think the area B experts re incompetent inArea A so they won't give them access. For the same reason, they won't do what the area B experts tell them is needed, because they don't believe it, because they "know" that area B people can never spot area A problems that the area A specialists haven't noticed. So they "know" it's not their problem. Of course if the area B people are equally overspecialised they can't spot errors in are A unless they've had a lot of experience of discovering how blid are the area specialists to things that are blatantly obvious to area B people, so the conflict never arises (and of course the problem never gets solved until a generalist takes a look at it).
You don't blame them. Well, I do. I've seen the consequences of the combination of overspecialisation with distrust between people whose topic of specialisation isn't the same and it's always bad news and often a disaster. And treating development DBAs and production DBAs as specialists in different areas is either bloody stupid pandering to those who are too damned lazy to learn what's needed for both those rôles or accepting idiot definitions of competence areas from ignorant managers who haven't a clue.
Tom
October 21, 2021 at 3:02 pm
Have any of you ever solved the problem of something in EE being used to easily identify and delete old files by session without having to jump through a flaming hoop because even dropping the event won't delete the .xel files?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 21, 2021 at 3:08 pm
To my knowledge, discipline is your only friend here. Keep the files in a defined place. Use naming standards that help you clarify what a thing is for, then clean stuff out occasionally. Sorry. Probably not the best answer.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 21, 2021 at 9:17 pm
That's exactly the conclusion that I came to but had to ask. Thanks, Grant.
As a bit of a sidebar, long live xp_CmdShell! 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply