The SQL Server 2000 Query Optimizer is one of the more complicated things that a SQL Server DBA deals with. For most of us, we just let it work and do not give it a second thought. But when a crisis occurred, Andy and Steve had to dive in to learn a few more things about it.
Day 2 from TechEd, this time from Brian Knight's perspective as the SQLServerCentral.com crew enjoys a week of learning and sun at the 2005 conference.
We would like to offer a free copy of the May 2004 SQL Server Standard magazine to everyone who can take a couple minutes to update some demographics for us.
They have been very hard at work trying to get SQL Server 2005 ready for release, but many of them have been given a week's break after IDW15 to come down to TechEd. They've created an interesting diary that you can view.
Occasionally, SQL Server database administrators are requested to provide a list of development SQL Servers, production SQL Servers and so on. Many articles, such as "Monitor Disk Space on Multiple SQL Servers" and "Inventorying hardware and OS information on all SQL Servers" require a list of servers in a text file.
It's not a SQL Server event, but SQL Server is a large part of it. TechEd is a huge conference and one of the premier events put on by Microsoft each year. Read about the first day with Andy, Brian, and Steve.
When a SQL Server object is created, its properties are called metadata. The metadata is stored in special System Tables. For example, in SQL 2000, when a new column was created, the column name and data type could be found in an internal System Table called syscolumns. All SQL objects produce metadata. Every time SQL 2000 Enterprise Manager or SQL 2005 SQL Server Management Studio is browsed, the information displayed about database, tables, and all objects, comes from this metadata.
SQL Server 2000 does a lot of things for the DBA, tuning, updating statistics, scheduling tasks, wizards and more. But one thing that it does not help with is choosing the correct data type for your data. New author Amit Lohia brings us a technique and some code that will examine your existing data and suggest places where another data type might be a better choice.
This paper will explain and show how standard ANSI SQL processors can naturally model and automatically process complex multi-leg hierarchical data structures at a full conceptual hierarchical level. This also means the query user does not need to have structure knowledge of the hierarchical structures involved. The data modeling capability includes dynamically combining logical hierarchical relational and physical XML data structures at a full hierarchical level. This also includes the ability to link below the root of the lower level structure intuitively forming a valid unified hierarchical structure. As will be shown, ANSI SQL’s high level hierarchical data processing allows the flexible conceptual control of hierarchical node promotion, fragment processing, structure transformation, and variable structure creation.
By gbargsley
Hello, dear blog reader. Today’s post is coming to you straight from the home...
By Steve Jones
This month I’m thrilled that Steve Hughes is hosting. I’ve read this Data on...
By Steve Jones
One of the things a customer asked recently about Redgate Data Modeler was how...
Comments posted to this topic are about the item Creating a JSON Document I
Comments posted to this topic are about the item Who is Irresponsible?
Comments posted to this topic are about the item Removing TDE
I want to create a JSON document that contains data from this table:
TeamID TeamName City YearEstablished 1 Cowboys Dallas 1960 2 Eagles Philadelphia 1933If I run this code, what is returned?
SELECT json_objectagg('Team' : TeamName)
FROM dbo.NFLTeams;
See possible answers