I know that are many people who think a DBA should know only about database. Ok, I’m sorry, this is wrong
A good DBA should know about database, of course! But if you stop on this layer you will be a “dba” and not a “DBA”!
Is highly important, for a DBA, the minimal knowledge about the OS behavior, and all I/O systems, as storage, network and memory.

Today, I will give some basic explanation about RAID levels. Which was also a gap on my knowledge.
First, I need to mention that we have two options of RAID: Hardware RAID and Software RAID.
In summary, the Software RAID is managed by OS, which implies in one more task to compete with the services running on it. So, for SQL Server environments, this is not recommended. Thus, I will focus on Hardware RAID Levels.

But, what are RAID Levels? Basically are the way that disks are grouped together, which is directly related with the Recoverability and performance.

I will talk about the most important for us: RAID 0, RAID 1, RAID 5, RAID 6, RAID 10 and RAID 0+1.

RAID 0: Striping

• Splits the data, so each drive have an equal portion of the data
• If 1TB is need, the capacity can be split in N drives arranged in a RAID 0
• More drives added, the faster it will perform, but a higher risk of a data loss
• Rarely seen in SQL Server implementations

RAID 1: Mirroring

• Keeps the same data on two (or more) HDs at all times.
• Bad cost-benefit
• Performance advantage for read operations because the same data exists on all drives
• Depending of the RAID Controller and amount of cache, there may be a write penalty
  • In most case the penalty is minimal
  • When a drive fails no data is lost
    • The failed drive can be replaced and a new copy of the data will be build
    • During rebuild process, performance will be degraded
    • RAID Controllers can be configured to set lower or higher priority on rebuilds against OS queries
    • SQL Server Logs can be placed on this RAID level

RAID 5: Striping with Parity

• Similar to RAID 0 in that each drive can share an equal part of the data
• Adds a measure of data protection: Parity Data
• Calculating this parity data is processor-intensive
• The minimum number of drivers is three
• Some hardware RAID controllers can add additional drivers on the fly
• It cannot recover from the failure of more than one drive

RAID 6: Striping with Parity

• Similar to RAID 5
• But the failure problem is solved storing more parity data throughout the array

RAID 0+1 and RAID 10 (Nested RAID Leves)

• Store two identical copies of the data on two separate sets of drive
• What is the difference between RAID 0+1 and RAID 10?
  • RAID 0+1: the data is striped and then mirrored
    • Handles only the failure of a single drive in each side
    • Best practice for log files and tempdb
    • Better protection from hardware failure and better write performance
    • “In general RAID 1+0 will provide better throughput for write-intensive applications. The amount of performance gained will vary based on the HW vendor’s RAID implementations. Most common alternative to RAID 1+0 is RAID 5. Generally, RAID 1+0 provides better write performance than any other RAID level providing data protection, including RAID 5.“
  • RAID 10: The data is mirrored and then striped
  • • Handles the failure of multiple drives in the same array, without loss.
    • In write intensive applications such as database log or OLTP environments, is the better choice

So, this is it! I hope it was helpful as an introduction

References:
http://technet.microsoft.com/en-us/library/cc966534.aspx
http://en.wikipedia.org/wiki/RAID
Christian Bolton , Justin Langford , Brent Ozar , James Rowland-Jones, Jonathan Kehayias, Cindy Gross, Steven, “Professional SQL Server 2008 Internals and Troubleshooting”,  ISBN-10: 0470484284 | ISBN-13: 978-0470484289

The information takes in considering seeks, scans and lookups and outputs the date of the last operation of each kind.

It’s important to remark that this statistics are cleaned every time the service is restarted!

SELECT Object_name(object_id),
SUM(user_seeks)       user_seeks,
SUM(user_scans)       user_scans,
SUM(user_lookups)     user_lookups,
MAX(last_user_seek)   last_user_seek,
MAX(last_user_scan)   last_user_scan,
MAX(last_user_lookup) last_user_lookup
FROM   sys.dm_db_index_usage_stats
WHERE  database_id = Db_id()
GROUP  BY Object_name(object_id)
ORDER  BY SUM(user_seeks),
SUM(user_scans),
SUM(user_lookups)

The virtual launch sessions of the SQL Server 2012 are already available!

http://www.sqlserverlaunch.com/

I recommend the session about AlwaysOn and ColumnStore Index.

Good learning for you

Problem 1:
A column of type “Text” on the side of MySQL.
Solution 1:
Create a column of type “Text”, in this case isn’t Unicode, in SQL Server table side.

Problem 2:
In the package, I cannot assign values ​​to respective OutputBuffer column of type “Text” (source for SQL Server). The “ReadOnly error”.
Solution 2:
You should assign values ​​to this type of columns as follows (You should change the encoding type!):

OutputBuffer..AddBlobData(Encoding.Default.GetBytes(“<SOME_STRING>”);

Problem 3:
How to read the contents of a “Text” column type (in MySQL side), returning a String?
Solution 3:
The following strategy should be used:

string str_notes = System.Text.Encoding.Unicode.GetString(Row.<COLUMN_NAME>.GetBlobData(0, Convert.ToInt32(Row.<COLUMN_NAME>.Length)));

I hope it helps and save you time

In summary, is a DBA onus maintains total attention on the following points:

• Security
  The database server security is not a meaning of anti-hacking system (only). Through the operating system is possible to reach the database server and its resources, and through the database server is possible to reach the operation system. For this reason, is extremely important the teamwork between system administrators and database administrators.
• Isolation
  This point could be a part of security, however is particularly important to isolate the access to each single database in the server, even though it is owned by the same entity.
• Recoverability
  As the data is stored in database system managed files, it is required (most cases mandatory) for the DBA to maintainto maintain a reliable backup strategy implemented, to recover the databases when is needed.
• Confidentiality
  All the applications have to be owned by someone at some point, and only these (or those) people can allow changes in the data and sending chunks of data or even the entire database.

Is normal to a DBA be faced with data corruption. It can be caused by some database engine fail, by a “wicked” DML/DDL execution or even by the application itself. To take care of data, and protect the DBA, some important rules have to be created:

• Data Changes (DML scripts)
  Is mandatory to any data change be authorized by the application’s responsible. A DBA cannot change the data without the corresponding permission. Adding to it, every data change have to be requested by the application owner and the DML scripts sent to the DBA team to be approved and executed without online modifications.
• Structure Changes (DDL scripts)
  A DDL script doesn’t change data directly, however, it can indirectly break the database integrity, corrupt data or carry performance problems in a non-distant future, because of it, a DBA’s verification before a creation or change of any database object is of high importance subject and must be followed carefully by the DBA.

The objective of this article was to demonstrate some ideas, based on experience, of possible points of protection, because as we know, the DBA is always the first in the line of fire…

Developing each of these point, will help to improve the QoS and protect the DBA team of possible mistakes.

If you have more ideias, critics or suggestions, do not hesitate to contact me!

Here comes a simple script to show a list of all columns of each table in a database.
It could be useful to help the know about database model.

DECLARE @obj_id INT
DECLARE @obj_name VARCHAR(300)
DECLARE @columns AS VARCHAR(MAX)

IF Object_id(‘tempdb..#tmp_table’) > 0
BEGIN
DROP TABLE #tmp_table
END

CREATE TABLE #tmp_table
(
table_name VARCHAR(300),
columns VARCHAR(MAX)
)

SET @obj_id=100

WHILE EXISTS (SELECT TOP 1 1
FROM sys.tables
WHERE object_id > @obj_id)
BEGIN
SELECT TOP 1 @obj_id = object_id,
@obj_name = Schema_name(schema_id) + ‘.’ + name
FROM sys.tables
WHERE object_id > @obj_id

SET @columns=”

SELECT @columns = @columns + name + ‘, ‘
FROM sys.columns
WHERE object_id = @obj_id
ORDER BY name

INSERT INTO #tmp_table
SELECT @obj_name,
Substring(@columns, 0, Len(@columns) – 1)
END

SELECT table_name, columns
FROM #tmp_table
ORDER BY table_name

Sorry for the lack of update, but my external disk was stolen with a lot of new pre-made articles inside

So, now let’s start from the start again !!
I expect that my lost articles can be useful for someone… Maybe we will have an ex-robber as DBA! This is “SQL Clever” helping the world be a better place

Ok, let’s go to SQL Server!!!

How is the best way to import/export/copy large tables?

Last week I’d the challenge of copy 512Gb of data, distributed in 5 tables, and it brought me a doubt about the best way to do this.

What is, for me, “the best way”?
“The best way” is a copy with some characteristics:
- A short time transfer
- Low CPU load
- Controlled use of T-log and tempdb

To reach this, I tryed three solutions. The first was the “Import/Export Wizard” from SSMS (SQL Server Management Studio), but in a simulation with 1% of a table did me exclude this hypothesis. I wasted 55 minutes to conclude the task.

After the first “fail”, I tried a more inteligent thing: Insert blocks with intermediate commits. It sounds good!

Following, an example:

– 0 to 1000
BEGIN TRANSACTION

INSERT INTO OrderDetails_copy (ID, Description, Discount)
SELECT ID, Description, Discount
FROM OrderDetails
WHERE ID BETWEEN 0 AND 1000

COMMIT TRANSACTION

– 1001 to 2000
BEGIN TRANSACTION

INSERT INTO OrderDetails_copy (ID, Description, Discount)
SELECT ID, Description, Discount
FROM OrderDetails
WHERE ID BETWEEN 0 AND 1000

COMMIT TRANSACTION

This is a great solution!!! But not for me My tables ID was VarChar!!!!! Nay, ALL THE COLUMNS was VarChar

Ok…Thanks to Microsoft, we have BCP utility!
The strategy is:

1) Copy from the database table to a file
bcp “DATABASE.SCHEMA.TABLE_SOURCE” out FILENAME.bcp -S”INSTANCENAME” -T -b10000 -n
2) Copy from a file into the database table
bcp “DATABASE.SCHEMA.TABLE_DESTINATION” in FILENAME.bcp -S”INSTANCENAME” -T -n -b10000

It’s done!
In this case, I’d used a batch size of 10000 rows, to optimize the process and reach “the best way”

The BCP Utility has a lot of parameters, for more info about BCP:
http://msdn.microsoft.com/en-us/library/aa174646(v=sql.80).aspx

I know that each case is a case, each database has its own behavior, each server has different limitations than others, but this article is only a baseline to help

in a startpoint. Maybe you can find/know a better way to do this (SSIS packages?), but here are a simple and efficient way to do the job.

Thank you for reading!
See ya

No entanto, aumenta a segurança limitando a disponibilidade da informação caso o sistema de segurança falhe.

Neste artigo iremos abordar o TDE (Transparent data encryption), que é o modelo de encriptação utilizado pelo SQL Server para cifrar arquivos de dados e logs de uma forma transparente, ou seja, sem a necessidade de alteração de código do software ou dos meios de acesso a instância. 

Como funciona o TDE?

O método de encriptação TDE cifra instantaneamente a informação contida nos arquivos de log e de dados nas operações de I/O. A criptografia é feita baseada em uma “database encryption key” (DEK), que fica registrada na página de boot do banco de dados, o que permite a sua disponibilidade durante o recovery do BD.

 Mais informações sobre a “boot page”: http://www.sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-20-Boot-pages-and-boot-page-corruption.aspx

 A DEK é uma chave simétrica protegida por um certificado guardado no “master” ou por uma chave assimétrica protegida pelo módulo EKM. 

O TDE protege os dados nos arquivos de dados e log, o que faz com que sejam cumpridas algumas leis, regulamentos e guias estabelecidos em vários ramos da indústria. Assim, é permitido aos desenviolvedores a utilização dos algorítmos AES e 3DES sem alteração do código do software. 

A encriptação é feita ao nível da página, isto é, as páginas de um banco de dados são encriptadas antes de serem escritas no disco e decifradas quando lidas para a memória. 

Algumas considerações:

• O TDE passou a existir a partir do SQL Server 2008 apenas.
• O TDE não encripta a comunicação.
• O tamanho do banco de dados não irá aumentar com a ativação do TDE.
• Backups comprimidos terão pouca efetividade.
• Nenhum filegroup pode estar marcado como read-only, caso contrário o processo de ativação do TDE irá falhar.
• Os dados FILESTREAM não são criptografados, mesmo quando TDE é habilitado.
• A tempdb passa a ser encriptada, se houver pelo menos um banco de dados encriptado na instância. Por este motivo, a performance em BDs não encriptados pode ser prejudicada
• Logo após a ativação do TDE é regra a execução do backup do certificado e chaves, caso contrário a base de dados poderá ser perdida em uma situação de desastre.

Usando o TDE

Para ativar o TDE em um banco de dados, deve-se executar o seguinte:

1. Criar uma master key
2. Criar ou obter um certificado protegido pela master key
3. Criar uma DEK (databse encryption key) e protege-la com o certificado do ponto 2
4. Habilitar o uso da criptografia no BD

 Como fazer isso na prática?

Abaixo passo o código passo-a-passo de como ativar o TDE em um pseudo banco de dados “Certtest”. Criei uma pasta “temp” no disco “D” com objetivo de guardar os backups, que serão usados na segunda parte do exemplo. 

USE master;

– Create a master key

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘masterkey123′;

 

– Create or obtain a certificate protected by the master key

CREATE CERTIFICATE MyServerCert WITH SUBJECT = ‘TDE Certificate’

GO

 

– Backup Master Key

OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;

BACKUP MASTER KEY TO FILE = ‘d:\temp\MasterKey.dat’

ENCRYPTION BY PASSWORD = ’123′;

 

– Backup certificate

BACKUP CERTIFICATE MyServerCert TO FILE = ‘d:\temp\MyServerCert.dat’

WITH PRIVATE KEY (FILE = ‘d:\temp\PrivateKey_MyServerCert.dat’,ENCRYPTION BY PASSWORD = ’123′)

 

– Backup service master key

BACKUP SERVICE MASTER KEY TO FILE = ‘d:\temp\S_Master_Key.dat’ ENCRYPTION BY PASSWORD = ’123′;

GO

 

 

use Certtest

go

– Create a database encryption key and protect it by the certificate

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128

ENCRYPTION BY SERVER CERTIFICATE MyServerCert

GO

– Set the database to use encryption

ALTER DATABASE Certtest

SET ENCRYPTION ON;

GO

 No código acima, além dos passos básicos, foram feitos backups do certificado e chaves, o que garante que não iremos perder o banco de dados, caso haja um problema grave com a instância. 

Feito isto, podemos verificar a ativação do TDE através das seguintes queries, que usam DMVs como recurso: 

USE Master
SELECT DB_NAME(database_id), *
FROM sys.dm_database_encryption_keys

SELECT * FROM sys.certificates

A primeira query devrá retornar duas linhas, com informação sobre o tempdb e Certtest, onde campos de interesse são: key_algorithm (algorítmo usado) e encryptor_thumbprint (hash do certificado que protege a chave). 

Na segunda query, são exibidos todos os certificados do servidor. No nosso caso o iremos ver o certificado MyServerCert, que deverá ter o thumbprint igual ao apresentado na query anterior para o BD Certtest.

Restaurar um banco de dados encriptado para outra instância 

Um grande problema dos BDs criptografados é a movimentação entre instâncias, por exemplo, um refresh de desenvolvimento. O que acontece é que se o BD está criptografado, a outra instância deverá ter o mesmo certificado e master key. Aqui temos duas opções:

• Desativar o TDE do banco antes de fazer a cópia e depois reativa-lo, o que não é recomendado.
• Restaurar as chaves e certificado na outra instância e manter o TDE ativo

 A primeira abordagem não é elegante, mas é funcional. A segunda opção é elegante, mas no caso exemplificado (refresh de produção para uma instancia de desenvolvimento) pode fazer com que elementos da equipe de dev tenham acesso ao certificado e chaves de produção, isso porque muitas vezes os desenvolvedores fazem parte da server role Sysadmin na instância de desenvolvimento. Uma forma de dar a volta a este assunto, é restaurar o banco de dados e depois desativar o TDE, apagando o certificado e chaves, ou até mesmo usar uma instância intermédia para copiar o banco encriptado, desativar o TDE e somente depois fazer o refresh. 

Independentemente do que for feito, segue o código para restaurar o certificado, as chaves e por fim o banco de dados com o TDE ativo (levando em conta o primeiro exemplo):

– Restore service master key

RESTORE SERVICE MASTER KEY FROM FILE = ‘d:\temp\S_Master_Key.dat’

DECRYPTION BY PASSWORD = ’123′;

 

– Restore Master Key

RESTORE MASTER KEY FROM FILE = ‘d:\temp\MasterKey.dat’

DECRYPTION BY PASSWORD = ’123′

ENCRYPTION BY PASSWORD = ‘masterkey123′

 

OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;

            ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;

CLOSE MASTER KEY;

go

 

– Restore certificate

USE Master;

OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′

            CREATE CERTIFICATE MyServerCert FROM FILE = ‘d:\temp\MyServerCert.dat’

            WITH PRIVATE KEY (FILE = ‘d:\temp\PrivateKey_MyServerCert.dat’, DECRYPTION BY PASSWORD = ’123′);

CLOSE MASTER KEY;

GO

 

OPEN MASTER KEY DECRYPTION BY PASSWORD = ‘masterkey123′;

            RESTORE DATABASE [Certtest] FROM  DISK = N’D:\temp\Certtest.bak’ WITH  FILE = 1, 

            MOVE N’Certtest’ TO N’<path_de_dados>\Certtest.mdf’, 

            MOVE N’Certtest_log’ TO N’<path_de_logs>\Certtest_1.ldf’, 

            NOUNLOAD,  STATS = 10

CLOSE MASTER KEY;

go

Após esta operação, você terá uma cópia do banco de dados com o TDE ativo em outra instância. 

Espero com este artigo ter atingido os principais pontos do TDE. Obviamente existe uma infinidade de situações que podem aparecer, como erros no restore do BD criptografado, mas é difícil expor tudo aqui. Caso surja alguma dúvida, sugestão ou correção de algo estarei disponível para ajudar ou atualizar o texto.

 Links e referências:
http://msdn.microsoft.com/en-us/library/bb934049.aspx

O MS DTC foi incluído a partir do Windows 2000 e também foi disponibilizado para Windows NT 4.0. Este recurso desempenha a função de coordenador de transações de arquiteturas COM e .NET. Na terminologia do MS DTC, o diretor (director) é chamado de gerenciador de transações (transaction manager).

No Windows Server 2008, o componente MS DTC suporta clusters ativo/ativo em que o recurso MS DTC em cluster (clustered MS DTC) coordena transações distribuídas em um grupo do cluster Windows.

Existem duas categorias de clusters para Windows Server: ativo/ativo e ativo/passivo.
No ativo/passivo, o nó passivo é utilizado apenas quando o ativo falha, já o ativo/ativo todos os nós são usados.

As últimas versões do Windows Server, como Windows Server 2003 e Windows 2000 Server, suportam o MS DTC em um cluster activo/passivo. Porém, existem limitações. Por suportar apenas um recurso MS DTC por cluster, alguns pontos negativos passaram a transparecer:

• Podem ocorrer problemas de isolamento, pois aplicativos diferentes compartilham a mesma DTC para a coordenação.
  Como apenas um recurso MS DTC serve todo o cluster, se alguma coisa der errado com o cluster DTC, por conta de uma falha aplicacional, todas as aplicações com transações coordenadas através do cluster MS DTC podem ser afetadas.
• O desempenho pode ser degradado, por conta da “falta de habilidade” de algumas aplicações em reagir a situações de failover.
  Por exemplo, quando um cluster MS DTC deve coordenar uma transação de uma aplicação que não está sendo executada no mesmo nó, pode existir alguma latência na mensagem de coordenação, o que pode gerar um timeout aplicacional.

No Windows Server 2008, já é possível a criação de vários DTCs em um failover cluster, seguindo os seguintes passos:

1. Criando múltiplos cluster groups no failover cluster.
2. Criando um recurso MS DTC para cada um destes grupos.

Para se aproveitar ao máximo a potência de processamento do cluster, deve-se criar tantos grupos quantos nós existentes no cluster, e distribuir estes grupos pelos nós disponíveis. Segue-se uma lista de benefícios desta abordagem:

• A falha de uma aplicação em cluster, não irá necessariamente prejudicar as outras aplicações.
  No Windows Server 2008 existe a possibilidade de se criar um recurso MS DTC por cada grupo.
• Não existem limitações de configuração para recursos MS DTC em cluster. Como é possível ter uma instância DTC em cada nó, alguns problemas, como a instalação de aplicações COM+ em e sua configuração em cluster foram resolvidos.
• Como cada grupo pode ter seu próprio recurso MS DTC, as latências antes existentes praticamente deixam de existir, por este motivo é possível que se note uma melhoria de performance aplicacional.

E o que é melhor para o SQL Server? A Microsoft sempre recomendou que não houvessem “misturas” no resource group do SQL Server, especialmente os que alteram as dependências. Porem, o sugerido é criar um recurso DTC por cada instância de SQL Server existente no cluster, adicionar este recurso no grupo da sua respectiva instância e apontar o log para um disco disponível no grupo.
Não é nem um pouco recomendável que o SQL Server ou o SQL Server Agent sejam dependentes do DTC, pois qualquer alteração a nível do DTC, como alterações de propriedades ou até instalações de hotfixes, irá fazer com que os serviços citados sejam reiniciados. Como esta configuração o SQL Server terá um MS DTC dedicado ajudando em transações, que possam gerar bottlenecks, entre servidores .

Alguns fatos:

• Se não existirem recursos MS DTC no cluster, o SQL Server irá iniciar a conexão pela instância local do MS DTC.
• Se existe um recurso MS DTC no cluster, então a primeira instância a ser usada será a padrão, utilizada pelas instâncias SQL Server. A instância MS DTC padrão poderá ser alterada através da console “Component Services Management”.
• Se existe um MS DTC no grupo do SQL Server, este será usado.

Criando um recurso MS DTC dentro de um grupo SQL Server:

1. No Failover Cluster Management, clique no respectivo resource group com o botão direito do mouse.
2. Clique em Add resource->Other resources->Distributed Transaction Coordinator.
3. Crie as dependencias do recurso MS DTC (network name e disco).
4. Clique com o botão direito sobre o recurso MS DTC e em seguida clique em “Bring Online”

Código para testar um transação distribuída (deverá retornar a mensagem “Command(s) completed successfully.”):

Begin Distributed transaction;
Commit Transaction;

Guia com a resolução de alguns problemas relacionados com o MS DTC:
http://www.sqlwebpedia.com/content/msdtc-troubleshooting

Fontes:

• http://technet.microsoft.com/en-us/library/cc730992%28WS.10%29.aspx
• http://blogs.msdn.com/b/sqlserverfaq/archive/2010/06/04/can-i-listen-to-you-mr-msdtc.aspx
• http://weblogs.sqlteam.com/geoffh/archive/2008/07/31/DTC-configuration-for-Windows-2008-SQL-2005-Clusters.aspx

Meu nome é Murilo Miranda, apenas mais um DBA neste mundo Porém espero que o blog SQL Clever não seja apenas mais um, e sim uma fonte de informação fiável e que principalmente traga algo de positivo aos visitantes.

O objectivo deste blog, não é apenas partilhar os resultados das minhas vivências e desafios na administração de SQL Server, mas também aprender com as dúvidas de terceiros e solidificar o que já conheço, pois acredito que ensinando aprendemos cada vez mais.

Tentarei sempre trazer informação em Português, pois vejo alguma carência na web de bons sites de SQL Server na nossa língua.

Porque SQL Server?

• Primeiramente porque eu trabalho com SQL Server
• Por ser o DBMS que mais cresce desde 2001
• É o produto mais escolhido para novos projetos
• Software de DBMS líder em plataforma Windows

Bem, ao contrário do que possa parecer, não sou um defensor da Microsoft, do Windows ou mesmo do SQL Server…Admiro Oracle e DB2 por exemplo, mas este é um Blog sobre SQL Server, ok?

Hoje fico por aqui. Espero em breve disponibilizar algo de interessante para vocês.

Até a próxima!

First of all, I welcome everyone on this new blog about SQL Server.

My name is Murilo Miranda, just one more DBA in this world But I hope that SQL Clever doesn’t be just one more blog, but a reliable source of information and wich especially bring something positive to you.

The purpose of this blog is not just share the results of my experiences and challenges in SQL Server administration, but also learn from the doubts of others and solidify what I already know, because I believe that, teaching we learn more.

I always will try to bring information in Portuguese (and also in English), because I belive in a shortage of good Web sites for SQL Server in my mother tongue.

Why SQL Server?

• Primarily because I work with SQL Server:)
• Because, since 2001, is the fastest growing DBMS
• It’s the first choice for new projects
• Leader for Windows platform

Well, I am not an advocate of Microsoft, Windows or SQL Server … I admire Oracle and DB2 for example, but this is a blog about SQL Server, ok?

That’s all for today, I hope to offer something interesting for you soon.

See ya