At least not completely. There are some functions in SQL Server that are built on the SQL CLR, and even if you have disabled the CLR for user written code, it still loads app domains and functions for system code.
An example of this is the spatial data type. It’s a SQL CLR written user defined data type, but written by Microsoft. If you create a spatial variable, the SQL CLR loads an app domain and code for the UDT using spatial data.
Not a big problem, and not a security risk from my standpoint, but it is worth knowing if you have to debug into memory or some detailed traces/events and see the SQL CLR loading. Don’t panic, and understand that you can’t prevent this from loading for these system objects.
It’s hard to believe that I have been running SQLServerCentral for almost ten years. I’ve thoroughly enjoyed it, hope I get to do it another ten years, and am thankful every day for having one of the best jobs in the world. It fits me well, and surprisingly, it’s a job I never expected to have as recent as 12 years ago.
When I started working full time for SQLServerCentral, I also started my telecommuting career. I hadn’t ever worked outside of an office on a regular basis before that time, and now I wouldn’t want to ever go back to an office full time. Aside from all the benefits of a flexible schedule and more time with my kids, the most valuable part of working at home is the lack of a commute.
IBM had a global commuter pain study recently, and this short video on eWeek highlights some of the results. I thought it was great that the study recognizes that there is pain involved in commuting, and the study talks about more than just lost time. There is evidence to support the idea that workers’ health is actually lowered over time from the stress and traffic issues in many cities.
I firmly believe that investing in your health is very important for your future. If you can reduce the stress and the time spent on unproductive actions, like sitting in traffic, you might actually find that you enjoy your job, and your life, more.
Many managers don’t want to let employees work remotely, but you should try to convince them to let you try it. Gather stories that prove remote workers are productive, or ask to implement a pilot program. Try to prove to your manager that you can be effective a day or two a week. After all, many of you are effective away from the office when you’re on call. Why not get permission to extend that to a few other time periods during the week.
I take the MCM test on Friday. I’ve been watching videos and reading white papers and blogs for the last few weeks and I know that I don’t necessarily know enough. To some extent I have an advantage since I test well on multiple choice tests and I have a broad set of knowledge for SQL Server.
But I don’t know enough. The more I study, the more it becomes painfully clear how much more there is to SQL Server that I don’t understand. Each day I learn something new, but I also learn that there are things I wasn’t aware of
Often, I find that things I just learned are things that friends already know. The thing that gives me some hope is that they will learn something and tell me, not realizing I already know about it.
We all have these uneven holes of knowledge, and just because we do, or don’t, know about feature X, doesn’t mean that we don’t know a lot about feature Y. We have un-evenly learned SQL Server since there isn’t a set path on which to learn.
So I’m nervous, just because it’s a measure of my skill, not because it matters to my career. It will give me a benchmark, and a place from which I can make a plan for how much more I want to learn about SQL Server, and in which areas to work.
Someone asked the question lately about archiving old data. This person wanted to purge data from old tables and was wondering if there was a way in SQL Server 2005 to detect the last time a table was accessed. While there is some data kept on tables being accessed (plans, potentially missing indexes, etc.) this data is not preserved forever and often is cleared in restarts.
With no reliable method for determining when someone last accessed a table, what can you do? It’s a question that DBAs face regularly now, and will face more often in the future. With data sets growing quickly, and storage budgets growing more slowly, the need to archive data becomes more prevalent all the time.
I hope at some point the metadata about table access will get built into SQL Server, but until that time you are on your own. If you can change the application code, you might be able to log this, but ultimately I think that you might end up making some type of guess about whether or not a table, or subset of a table, is still being used.
Once you do that, there are multiple ways to archive off the data, but no matter how you build a process, make sure that you can do one thing: restore the data. Someone can understand you making a mistake in which data to archive, but they won’t likely understand if you make a mistake in restoring it.
Voice of the DBA 