You can achieve this by Right click the database, go to 'Generate Scripts', Advanced, 'Script to Server Version' option.

If the db is too large, script out just the database structure, then use your favorite method (SSIS, BCP, Import Wizard) to push the data.

-Karthik (Database Consultant)

USE AdventureWorks
GO
SELECT object_name(IPS.object_id) AS [TableName], 
 SI.name AS [IndexName], 
 IPS.Index_type_desc, 
 IPS.avg_fragmentation_in_percent, 
 IPS.avg_fragment_size_in_pages, 
 IPS.avg_page_space_used_in_percent, 
 IPS.record_count, 
 IPS.ghost_record_count,
 IPS.fragment_count, 
 IPS.avg_fragment_size_in_pages
FROM sys.dm_db_index_physical_stats(db_id(N'master'), NULL, NULL, NULL , 'DETAILED') IPS
 JOIN sys.tables ST WITH (nolock) ON IPS.object_id = ST.object_id
 JOIN sys.indexes SI WITH (nolock) ON IPS.object_id = SI.object_id AND IPS.index_id = SI.index_id
WHERE ST.is_ms_shipped = 0
AND IPS.avg_fragmentation_in_percent>=20
ORDER BY 1,5
GO

If you don't want to monitor the percentage of fragmentation yourself and you want to give someone the permissions to view this information, execute the following:

USE AdventureWorks2012;
GO
GRANT VIEW DATABASE STATE TO [domain\user_account];
GO

DO NOT give db_owner permission :-)

This blog is just an example of what level of permission need to be provided to the application users so that we DBA's can avoid having to provide such reports ourselves and educate your application developers to do the right thing.

-KKB

Note: Fragmentation is not a problem, what's causing too much fragmentation is the problem. If you're successful in identifying a stored procedure or a statement which caused your box to go 100% CPU, check the query plan of that articular query during the issue and during when the CPU is 40-80%. Understand why, when we have a bad performance, the SQL Server took the bad plan and see if you can improve the performance.

Sometimes DBCC CHECKTABLE, DBCC CHECKALLOC and DBCC CHECKCATALOG are not enough unless you tweek it according to some logic, anyways, the below command will make sure you haven't left anything un-turned from SQL end.

EXEC sp_msforeachdb 'DBCC CHECKDB(''?'') WITH ALL_ERRORMSGS, EXTENDED_LOGICAL_CHECKS, DATA_PURITY'

If you feel that you need to run the DBCC CHECKDB on the MDF (live, not snapshot) then use TABLOCK.

Tip: In Enterprise edition of SQL Server, the DBCC CHECKDB need not be single-threaded operation but in other editions of SQL Servers, DBCC CHECKDB is always single-threaded operation. In the SQL Server ERRORLOG, you'll see generation of minidump which is normal every time you run DBCC CHECKDB. SQLIOSim is a good command line utility to point out the problem with your underlying disk subsystem. 

-KKB

I was working on an OLTP environment where tempdb started growing crazy! Before even I got a hold of the server, someone restarted the SQL Service and had a smile on his face (thinking he solved the problem), well, tempdb hadn't learnt it's lesson from this guy :D

I got hold of queries from this link and created a job to understand (one) which spid consumes the space, (two) what's the allocated KB and the de-allocated KB and (three) which query is eating my disk. I scheduled the job to run every 5 minutes (so that I don't miss the allocate and de-allocate pattern) and redirected the output to a text file! (Some of you are laughing at me now, yes, reading a text file for analysis is difficult.

Why not append the output to our SQL Server :-) 

Yes, that's simple. Say I have this query which I want to push to a sample table from where I want to analyze; use this technique. (Query window)

This will create a table (which you can use to append your data).

In the job, use the below script to append data into that table. (Job Step)

This way, you can have your user table house the data of interest and not worry about how to read it during the analysis.

-KKB

Great reference article from Sudarshan (who was my technical lead while I was working at Microsoft): http://thesqldude.com/2012/05/15/monitoring-tempdb-space-usage-and-scripts-for-finding-queries-which-are-using-excessive-tempdb-space/

Why would I write a blog about it? Everything goes fine until we have the system databases working, the moment we don't have backups for system databases, we lose logins, metadata information, information about replication in case you lose distribution database, and most importantly, when your team relies on you to perform any RCA!!! (Now, I'm sure you'll say, YES)

Say you have around 800 instances, pull out a report on how you have configured the backups for system databases (some of your instances would be installed in C drive and the system databases go inside C drive but you'll not have backup strategies for C drive, you'd have it only for data & log drive.)

Master database

Do I need to take the backup? Big yes. 

Default recovery model is simple 

Note: If you perform any change ("Change management"), you perform the backup/restore for your user database but you tend to forget taking a full backup of master database. Don't do that! Backup your master database also, after-all it's master ;-)

Model database

Even though it's just a template, if you made any standard changes, you'll need a full backup of model database to retain that change in case of disaster.

The recovery model is user configurable. However I'd keep it simple as we hardly make changes to model.

Msdb database

Yes, msdb backups are required. I have restored msdb databases 100's of times as a user database to get the metadata information while performing the RCA (say a database was dropped due to corruption and later restored from a good known backup but you'd want to know which pages were bad before it was dropped as a part of RCA.) You can go back and search for msdb..sys.suspect_pages to get that information.

Resource database

Big no! Simply because you can't back it up. It's a read-only database and yes, I'll not waste your time on this.

Tempdb database

You cannot back up the tempdb system database. You'll know what tempdb is for, "A workspace for holding temporary or intermediate result sets. This database is re-created every time an instance of SQL Server is started. When the server instance is shut down, any data in tempdb is deleted permanently". So that explains it all.

Distribution Database

It only exists if you're using replication which (unfortunately) is true for most of the enterprise companies! Just kidding! It has several features which cannot be replaced by any of the other DR/HA solutions, we'll discuss about that some other day. The default recovery model for distribution is simple and that's enough.

OK, I accept, it's a simple blog (Picks from Technet article). My request to whoever reads this blog is to add their experience in the comments section which you think goes with the subject and I'll add that information post validation.

-KKB

I worked in Microsoft IGTSC for 4 years. Spent sleepless nights (because I was working :p) and spent good days during days while I was working for US after-hours business on SQL Azure technologies.

In this period, I gained a lot of technical skills. With the same spirit I joined my second company ANZ as a Technical consultant. I am a person who is happy with what I am doing and I love to say that I see my future very clear in this field.

Today is the start of my next initiative - what did I learn today?

I am sure we learn a lot of stuff at job and do not see the importance of sharing our learning with others but what I observed over time is, every bit of knowledge sharing is important so some soul who's in a hurry to fix something, design something, build something! 

I have been trying to figure out what's out there which'll earn you value in terms of technology. I saw a video on Python with 6 lines of code we could achieve what we could do using C (no, I'm not judging C; I love C too!)

Well, I better start writing what I learnt today!

-KKB

If (New-Object System.Net.Sockets.TCPClient -ArgumentList 'xxxxxxxxxxx.database.windows.net',1433) { Write-Host 'YES' } If ($? -eq $false) { Write-Host 'NO' }

One of my customers has an intermittent issue with connectivity within an Azure VM. 

See the screenshot below:

Above picture shows, the customer was not able to connect intermittently to the same server. 

-KKB

This is KKB from SQL Server world!

1. Open Command prompt, on Windows 7 or above choose to "Run as Administrator"
2. type:
   cd %temp%
3. Type following command line exactly as it appears with the variables:
   whoami /all > %username%_%computername%_Perms.txt
4. Open your <actual_username>_<actual_server_name_Perms.txt
5. Under Group Names verify you see:
   BUILTIN\Administrators
6. Now scroll to bottom and the PRIVILEGES INFORMATION sections
7. Look for the following privileges, ignore the State column, this shows if currently being used. As long as the privilege is listed, it is granted, if you had to add the permission user must logout and log back in to take effect.

Tip: Disks on Failover Clusters can fail to appear if BUILTIN\Administrators removed from:

With the privileges noted above any SQL Server setup should normally complete unless, local BUILTIN\Administrators has been limited (Hint: weird group policies!).

This is KKB from SQL Server world!