I recently needed to recover a database without backups or a transaction log and discovered the "-O" switch which, according to http://nntp-archive.sybase.com/nntp-archive/action/article/%3C3850ECE1.F29E6FBC#ictsoftware.de%3E, "is used for recovery purposes. It should only be used in rare situations where you cannot start the database and backups are not available."
This switch is not documented anywhere I could find.
My question is two fold: what exactly does the -O switch do, and is there any way to do what the -O switch does via START DATABASE command from the utility_db?
Undocumented switches are undocumented for a reason, usually because they're very dangerous. It's recommended that you never use any undocumented switches unless specifically advised to do so by SQL Anywhere support. I'm not going to answer the first question directly other than to say that this switch can be used during recovery but only in very specific circumstances. Use in any other circumstances can result in data loss.
The answer to the second question is no, there is no syntax (documented or not) that will make the START DATABASE statement do the same thing.
Disclaimer: I work for SAP in SQL Anywhere engineering.
Related
We are looking to implement unit tests using the tSQLt test framework. It has got a pre-requisite that the SQL CLR must be enabled using this command:
EXEC sp_configure 'clr enabled', 1; RECONFIGURE;
I am curious to know what is the purpose of SQL CLR and the risks of enabling this in production environment?
PURPOSE
SQLCLR allows one to do things that either:
can't be done in T-SQL, or
can't be done as efficiently as in T-SQL
There are plenty of things that can be done in both, and for which T-SQL is actually much better at. In those cases it is an inappropriate use of SQLCLR to do those things so it is best to research first to make sure that the operation cannot be done in T-SQL, or would definitely be slower.
For example of performance, T-SQL Scalar UDFs prevent parallel execution plans. But SQLCLR scalar UDFs, as long as there is no data access and that they are marked as IsDeterministic=true, do not prevent parallel execution plans.
For more details on what SQLCLR is and is not, please see the first article in the Stairway to SQLCLR series that I am writing for SQL Server Central:
Stairway to SQLCLR Level 1: What is SQLCLR?
Or, to get a sense of what can be done in SQLCLR, please see my SQL# project, which is a library of over 320 stored procedures and functions, many of which are in the Free version, and many of which work in SAFE mode: SQLsharp.com.
RISKS
The risks vary based on the PERMISSION_SET (i.e. SAFE, EXTERNAL_ACCESS, and UNSAFE) that the Assembly is marked as, and what is being done. It is possible to do things in an UNSAFE Assembly that cannot be done in regular T-SQL (except that many of those dangerous things can already be done via some extended stored procedures, xp_cmdshell, and the OLE Automatic procedures -- sp_OA* ). An Assembly marked as SAFE cannot reach outside of the database, so generally quite safe, BUT you can still lock up the system via a Regular Expression that exposes "catastrophic backtracking" (of course, this can be mitigated starting in .NET Framework 4.5, so SQL Server 2012 and newer, by setting a max time limit on the RegEx operation). An Assembly marked as UNSAFE can write to static variables, which in the context of the shared App Domain model used by SQLCLR, allows for shared memory between Sessions. This can allow for caching, but when not used properly, easily leads to race conditions.
TESTING
As for tSQLt, I do not believe that you are required to use the SQLCLR component. I thought I saw that it just enabled some extended functionality. Either way, the source code is available on GitHub so you can check it out to see what it is doing. It has been a while since I looked at it, but from what I remember, it should not present much of a risk for the little that it is doing (especially in a Dev / QA environment).
Another option that doesn't use SQLCLR is DbFit. I have always prefered DbFit as it is completely external to the DB. It is based on the FitNesse framework, written in Java, and you manage the tests via wiki-style pages. It, by default, wraps the tests in a Transaction and rolls everything back when the test is finished (i.e. clean-up). It is worth taking a look at.
Download: DbFit project on GitHub
Tutorial: Using the DbFit Framework for Data Warehouse Regression Testing
SQLCLR allows you to create .NET assemblies and run code inside them from within SQL Server.
Depending on the permissions on the assembly the risks vary. The risks are something like so:
Permission Set: Risk
SAFE You cannot do anything more than what you can in T-SQL. So fairly safe.
EXTERNAL ACCESS You can call code in .NET assemblies approved by Microsoft, such as ADO.NET. Fairly safe, but still a risk.
UNSAFE You can do almost anything that the .NET framework allows you to do. In reality, shoot yourself in the head unless you know what you are doing.
I am working on some stored procedures at a client site.
To debug stored procedures using SSMS, it seems you must be a member of the [sysadmin] group. However, they only have PROD and TEST database instances, and the DBA will not grant me these permissions.
According to him, using inline PRINT statements is considered to be just as good as the ability to debug. That doesn't seem quite right to me so I was thinking of escalating my request, but thought I'd first ask here, is this common sentiment in the industry (that the ability to debug is "not necessary")?
Though bit opinion based question but yes I have always used debug like that ... that is get the procedure body and run each code block separately to find where the problem is and fix accordingly.
You might also want to consider the execution plan of the procedure which will help in debugging.
In my experience, yes.
I once found the debugging functionality very useful when I was transitioning from being a ASP developer to a SQL developer, but as I've become more comfortable with SQL, I find that I can do all my debugging with PRINT statements.
Also in addition to being a sysadmin, did you know that you have to be running the debugger locally on the SQL server to use it? It's a lot more trouble than it's worth.
I came to know about some uses of undocumented stored procedures (such as 'sp_MSforeachdb' ...etc) in MS SQL.
What are they? and Why they are 'undocumented'?
+1 on precipitous. These procs are generally used by replication or the management tools, they are undocumented as the dev team reserves the right to change them any time. Many have changed over the years, especially in SQL 2000 Sp3 and SQL 2005
My speculation would be because they are used internally and not supported, and might change. sp_who2 is another that I find very handy. Maybe management studio activity monitor uses that one - same output. Did I mention undocumented probably means unsupported? Don't depend on these to stick around or produce the same results next year.
sp_MSforeachdb and sp_MSforeachtable are unlikely to change.
Both can be used like this:
EXEC sp_MSforeachtable "print '?'; DBCC DBREINDEX ('?')"
where the question mark '?' is replaced by the tablename (or DB name in the other sp).
Undocumented means unsupported and that MS reserves the right to change or remove said commands at any time without any notice whatsoever.
Any documented features go through two deprecation stages before they are removed. An undocumented command can be removed, even in a service pack or hotfix, without any warning or any announcements.
It is most likely that one of the internal SQl Server developers needed these stored procedures to implement the functionality that they were working on, so they developed it and used it in their code. When working with the technical documentation people they covered the scope of their project, and included in the official documentation only the portion of their project that applied to the customer. Over time, people found the extra stored procedures (because you can't hide them) and started using them. While the internal SQl Server developers wouldn't want to change these undocumented procedures, I'm sure they would in two seconds if they had to to for their next project.
As others have said, they are unsupported features that are not intended for general consumption, although they can't stop you from having a go, and indeed, sometimes they can be very useful.
But as internal code, they might have unexpected side-effects or limitations, and may well be here one day and gone the next.
Use them carefully if you wish, but don't rely on them entirely.
I am not a DBA by any means, but being a web developer means that I will have to install, setup, and administer databases. In the past, I have just followed the default installation for SQL Server. Over time, I have grown smarter and learned that default installations almost always leave doors open and leak.
So...What are the critical settings that should be thoroughly evaluated when installing SQL Server 2005 for someone of my caliber? or 2008? Or is every setting "critical?"
Any good resources that will guide through a "proper" setup of SQL Server 2005?
Every setting is critical - but the things I always double check are:
Authentication type - Integrated or SQL? If SQL, make sure you put in a very strong sa password.
Service Accounts - think through what you want for the accounts. I generally create a domain user for each service separately, and run them with least priviledges.
database paths. Decide up front where you want your system databases & user databases - its much easier to do that during the install than deciding after the fact.
Though this has mostly gone away with 64-bit, I always make sure that "AWE" is enabled if SQL is the only thing running on the server and it's 32-bit. This way, SQL Server has access to all the memory the server has (up to 3GB in a 4GB server) instead of being restricted to the normal 2GB.
I second the opinion that they're all important, and they all have different purposes, so it's a matter of your environment.
Most settings can be accepted with the default settings. SQL 2005 has been changed to be more secure by default.
Be sure to do the steps to prepare accounts to use.
You might also look at your server hardware and try to separate OS, SQL Binaries, Data and Logs onto separate drives.
http://msdn.microsoft.com/en-us/library/ms143516.aspx - for all the juicy details.
Post install, you should set up dbmail and then set up maintenance plans that notify you on failure of backups or maintenance.
Drive configuration! Where you'll place your log and database files is of absolutely paramount importance in terms of performance
My number one setting to check is the server's collation. This will control the collation of the system databases, and you should ensure that the new server's collation is the same as the old one to avoid collation errors. Ideally your user database will be the same collation.
If the two collations are different, and you compare varchar data from TempDB to varchar data from your user database, you'll need to specify the collation.
Just about every other setting can be changed later, but server collation is one that you're stuck with for keeps. (Technically, you can rebuild the system databases with a new collation, but it's not worth the effort, and still requires you to run Setup again).
The Microsoft documentation in Books on Line and elsewhere is pretty thorough and accurate. I think it's the best documentation that Microsoft does. So I'd be rigorous about "RTM" before anything I would write here, which would be incomplete and inadequately explained in any case by comparison.
That said, the first priority should be Do No Harm. I've seen many more cases where imperfect understanding of the consequences of changing the settings has caused problems, than that the default settings need to be altered. (Note: This advice does not apply to MySQL, whose defaults are pretty random IMHO.)
Recently a friend and I were talking about securing stored procedure code in a SQL server database.
From distant memory, I'm pretty certain that "with encryption" is incredibly easily broken in all versions of SQL Server, however he said it has been greatly improved in SQL 2005. As a result I have not seriously considered it as a security option in any systems I have ever worked on.
So in what scenarious could "with encryption" be used, and when should it be avoided at all costs?
It can be used to hide your code from casual observers, but as you say: it's easily circumvented.
It really can't be any other way, since the server needs to decrypt the code to execute it. It's DRM, basically, and fails for the same reason as all the other DRM does - you can't simultaneously hide the data, and allow it to be accessed.
#Blorgbeard
Good response, the MSDN documentation on "WITH ENCRYPTION" seems to agree with your point, now calling it "obfuscated" rather then encrypted.
I've met a few developers who were completely unaware of this point however. Hopefully this question/response will inform others too.
Yes, it's easily broken. I had a situation this past week where I had to decrypt several sprocs that a former developer had encrypted for a client of mine. After decrypting it, which took a moderate effort, I wouldn't rely on that for any means of protecting intellectual property, passwords, user ids. Anything really.