In snowflake,
'show tables like ' command is not showing 'automatic clustering on' column. i have added a clustering key to the table & now, i am trying to add search optimization and command is getting rejected saying that the automatic clustering is not on. has anything changed in snowflake recently, which is not available in documentation ?
Search optimization is in public preview and may require support double check to see if your account is enabled with the right parameters etc. Please open a support case to get the follow-up. Thank you.
Seeling
Even though Search Optimization is in public preview but the Search Optimization service has to be enabled at the account level along with Automatic Clustering services before it can be used.
If you are issuing below command
alter table <table_name> add search optimization;
and getting error like "Search Optimization requires Automatic Clustering to be enabled" then please get in touch with Snowflake Support.
Please note that for Search Optimization service to be enabled for Snowflake account, it has to be Enterprise Edition and above.
https://docs.snowflake.com/en/user-guide/intro-editions.html#sql-support
https://docs.snowflake.com/en/user-guide/search-optimization-service.html
Related
The documentation for Database Migration Assistant claims that it will identify and flag any "deprecated features". However, this does not seem to be true in the least. I have a SQL Server on-premises database full of features that Microsoft's documentation considers to be deprecated. However, DMA does not detect ANY of these things in an assessment targeting Azure SQL Managed Instance.
Documentation:
Overview of Data Migration Assistant
Numerous "deprecated" features, such as returning result sets from triggers, using deprecated hash algorithms in the HASHBYTES function, and so on, are not appearing at all in the assessment results. Clearly, the documentation is incorrect.
Am I missing something here?
We have some Premium Azure SQL Databases, and we are attempting to use indexed views to materialize a subset of some larger tables, so the data can be used in some search / reportring queries. What I am noticing is that the query optimizer refuses to use the view.
My first attempt was to create the view and not modify the query. I thought the optimizer would substitute the view when it determined it was a better choice, but it didn't.
My second attempt I selected from the view directly, the execution plan didn't change at all.
Finally I added the (NOEXPAND) hint on the view and this time the plan did use the indexed view.
I've seen this behavior with 3 different indexed views in 3 different queries. In all 3 cases the queries performed at several orders of magnitude better. In my most recent example the duration of the query went from 90 seconds to 1 second.
I'm not a big fan of using hints to override the query optimizer, has anyone else experienced this?
Indexes views are fully supported on Azure SQL Database Premium. No functionality of indexed views is blocked or not supported on Azure SQL Database.
To be able to help you, you will have to share the database schema and a step-by-step procedure of how your reproduce the issue. I guess you won't agree to share the schema on this site, so maybe the best you can do is create a support ticket at Azure Support. Please send an email to this (azcommunity#microsoft.com) address explaining the issue, they will return instructions to have this handled by Azure Support. They will safely take a look at your schema.
I want to know how can I know the relationship in the database which is not determined by the primary key in the design
For example I have three tables in the database following like this :
Table 1 : fields
Table 2 : area
Table 3 : location
and all of the tables have data but who created database did not explain the primary keys and the foreign keys in it, so how can i know the relationship between this tables?
Note : I am using SQL Server 2008
If there's no documentation at all and no defined foreign keys, your options are:
Look at the application source code to see what it's doing. This may or may not be available to you. If it isn't, you're in a fair bit of trouble.
Contact whomever wrote the application originally and ask them for help or documentation. This may or may not be possible.
Guess. I'm certain you'll have to do a lot of this no matter what.
Run the application while SQL Profiler is Trace Capturing the SQL queries sent to the DB, or using Extended Events in SSMS. I don't recommend running Profiler on a production DB due to the performance impact. I've never used Extended Events, but I know that they're replacing Profiler's capture abilities in forthcoming editions of SQL Server. Neither of these tools is particularly simple (Profiler isn't; Extended Events don't look any better from the doc). You're going to need to read a fair bit of documentation.
We are putting together a set of standards for our database. I am worried that down the road people will forget the standards or new developers will come online and not bother to use them.
I am wondering if there is a tool to audit standards and provide a report based on the standards. I would like it to include things like naming conventions for columns to not having GUIDS as the primary key.
Apex SQL used to have a tool like this called Enforce. But they discontinued it. Is there any such tool still on the market?
You can do a lot of things like this with Policy-Based Management. For example, here are a few tips I wrote for mssqltips that describe how to do a couple of things:
Enforce database naming conventions
Identify SQL Servers with inefficient power plans
Find unused indexes
Find all columns of a specific data type
Some various tips by other authors as well:
SQL Server Policy Based Management Tips
The sky's the limit, really. Anything you can run a SQL query to get a scalar result (and several other things as well), you can check with PBM.
For object-level stuff, you can get a good part of the way there using simple DDL triggers. For these you can simply hook onto DDL events (e.g. CREATE TABLE) and roll back if your naming conventions or other criteria are not being upheld. They work very similar to a DML trigger for modifying data in a table.
Just keep in mind that you can't always enforce everything, for example you can't rollback things that aren't "transactionable" (such as CREATE DATABASE) using either PBM or DDL triggers. And be careful where you put your "on change prevent" type of enforcement - for example rolling back a CREATE INDEX that took 12 hours isn't going to go over very well if it was rolled back only because it wasn't named correctly.
SSW of Australia also has a really nice tool for this called SQL Auditor.
They check SQL Server databases against a whole slew of "best practice" rules and give you a report on how you do according to their ruleset.
In the place I work, very often it happens that a developer and QA session goes like this:
(This is in reference to SQL Server 2005)
QA: I get Invalid object name 'customers'
DEV: huh? can u send me the exact SQL statement you used?
QA: select * from customers
DEV: hmm. (after some thinks) Are you sure you're using CUSTDB?
QA: yes
DEV: (after figuring out that QA was using CUSTDB_PRODUCTION) Please add "USE CUSTDB" and then tell me what you get with that SQL.
QA: Oh, sorry, I was using wrong DB.
The tab-text for the SQL window shows the information of which database the query is running on, but how do you ensure that QA follows this?
I will admit that I have made this mistake of using the wrong DB many times. I don't tend to read the text in the tab.
What are your experiences with this type of scenario? Have you found a way to help mitigate such a problem?
if your QA is using SSMS for testing you should try the window coloring options in SSMS Tools Pack free add-in for SSMS. this way you could immediately differentiate between servers.
if that's not an option don't allow QA to access production server at all. they shouldn't be able to anyway.
I think you need to formalise how QA will report an error.
You need to specify a set of information that they'll supply with every error report, including:
what they were doing (exactly)
their configuration (including the database!)
time/date (so you can match stuff in logs)
how to repeat it (if repeatable)
etc. You can act on that immediately, or log it in an incident tracking system and come back to it later (in which case the above is invaluable, otherwise it's all lost).
The above can be as simple as an email draft/template. But you need to be rigorous about this, otherwise (as you've discovered) you're going to go round in circles, perhaps without all the salient information you require.
If QA are allowed access to both live and dev databases, using SSMS, then there must be some level of accepted responsibility on their part and/or some level of training of them on your part.
They have been given a tool that allows them to ask questions of the data, but are asking the wrong questions, then complaining to you - if I was the DBA, I'd simply remove their access until they could demonstrate they knew what they where doing! I sympathise that that might not go down to well, but at least threatening to do it might make them think a little for themselves.
Think of this question as 'someone is doing something wrong'
There are 2 simple answers:
remove their ability to 'do something wrong'
train them to do it right
On the same note as Mladen Prajdic, you can colour code query windows in SQL2008 SSMS too.
Personally I use the fully qualified name in all queries (server.datatabase.owner.table - well I only use server if I'm deliberately using a linked server) because I move from database to database so much. If you specify the database in the queries to be run, they still work if connected to a differnt database on the same server or if you have a linked server. Have your QA adopt doing this as their standard if they are writing their own queries; if you are writing the test queries then you should be specifying the database name in the query not through a use statment.