SQL Server - Obtendo a porta de conexão através de uma instrução SQL

Olá,

Neste artigo rei demonstrar como podemos obter a porta que a instância do SQL Server está atendendo através de uma instrução SQL. Essa instrução é válida tanto para instalações Linux quanto para Windows.

[root@linux /]# sqlcmd -S localhost -U SA -Pminhasenha
1> DECLARE @test varchar(20), @key varchar(100)
2> if charindex('\',@@servername,0) <>0
3> begin
4> set @key = 'SOFTWARE\MICROSOFT\Microsoft SQL Server\'+@@servicename+'\MSSQLServer\Supersocketnetlib\TCP'
5> end
6> else
7> begin
8> set @key = 'SOFTWARE\MICROSOFT\MSSQLServer\MSSQLServer\Supersocketnetlib\TCP'
9> end
10> EXEC master..xp_regread @rootkey='HKEY_LOCAL_MACHINE',@key=@key,@value_name='Tcpport',@value=@test OUTPUT
11> SELECT 'Server Name: '+@@servername + ' Port Number:'+convert(varchar(10),@test) port;
12> GO

port
-----------------------------------
Server Name: linux Port Number:1433

(1 rows affected)

MongoDB - Um pouco sobre o db.setProfilingLevel()

Olá,

No MongoDB, por padrão, todas as operações executadas nos banco de dados da instância que gastam mais de 100 ms para serem executadas são armazenada no arquivo de log em um arquivo texto. Dependendo do ambiente, esse tempo pode ser aumentado ou diminuído. É possível alterar esse comportamento da instância executando o comando db.setProfilingLevel(). Ao conectar na instância do MongoDB podemos ver que a configuração atual do parâmetro slowms é 100 ms. O primeiro parâmetro mostrado na saída do comando db.getProfilingStatus() ("was" : 0) é nível de detalhes que são enviados para o log. O padrão é 0 e inclui informações mais simples. O valor máximo que pode ser setado para esse nível pode ir de 1 a 5 e pode ser utilizado para debug das operações executadas na instância do MongoDB com informações mais detalhadas.

[mongodb ~]$ mongo --host localhost --port 27017
MongoDB shell version v4.0.17
connecting to: mongodb://localhost:27017/?authSource=admin&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("41d40407-eb0e-4e45-b9b9-7882d4a30fcc") }
MongoDB server version: 4.0.17

> db.getProfilingStatus()
{ "was" : 0, "slowms" : 100 }

Agora irei aumentar o valor slowms para 500 ms.

> db.setProfilingLevel(0,500)
{ "was" : 0, "slowms" : 100, "ok" : 1 }

Para checar a alteração realizada, bastará executar novamente o comando db.getProfilingStatus() para ver o valor atual.

> db.getProfilingStatus()
{ "was" : 0, "slowms" : 500 }

MongoDB - Capped Collection

Olá,

No artigo de Março/2020 eu comentei sobre índices TTL no MongoDB que pode ser criado para automaticamente remover documentos da collection de acordo com o valor especificado na propriedade expireAfterSeconds do índice. Agora irei comentar sobre capped collections. Uma collection no MongoDB pode ser criada para que o seu tamanho não ultrapasse um tamanho definido em bytes. Se por acaso quisermos criar uma collection chamada "log_events" na qual seu tamanho não ultrapasse 5MB, poderemos utilizar a sintaxe abaixo para criá-la.

db.createCollection( "log_events", { capped: true, size: 5242880 } )

Nesse caso o MongoDB irá se encarregar de que os documentos mais antigos sejam excluídos de forma a dar espaço para os novos documentos inseridos e assim mantendo o tamanho máximo da collection em 5MB.

Caso queiramos limitar também o número de documentos dentro da collection, poderemos utilizar o parâmetro "max" como no exemplo abaixo na qual limito o tamanho da collection para 5MB até um total de 100 mil documentos.

db.createCollection("log_events", { capped : true, size : 5242880, max : 100000 } )

Vale a pena salientar que um documento dentro de uma capped collection não pode ter seu tamanho alterado após a inserção. Caso isso ocorra, o erro abaixo será emitido.

Command failed with error 10003: 'Cannot change the size of a document in a capped collection: 608 != 1601' on server.
The full response is {"ok": 0.0, "errmsg": "Cannot change the size of a document in a capped collection: 608 != 1601", "code": 10003}

Uma capped collection não pode ser revertida para uma collection normal, mas é possível alterar uma collection normal para uma capped collection conforme a seguir.

db.runCommand( { convertToCapped: "log_events", size: 5242880 } )

MongoDB - Índice TTL (Time to Live)

Olá,

O MongoDB possui um índice especial que pode ser criado para automaticamente remover documentos da collection de acordo com o valor especificado na propriedade expireAfterSeconds do índice. Vale a pena salientar que um índice TTL somente pode ser criado em um campo simples, não sendo permitido criar um índice composto. No exemplo abaixo irei criar uma collection chamada log_events e inserir 3 documentos em tempos diferentes.

> use bd01
switched to db bd01
> db.getCollection("log_events").insert({"createdAt": new Date(),"logEvent": 1,"logMessage": "Successo!"})
WriteResult({ "nInserted" : 1 })

> db.getCollection("log_events").insert({"createdAt": new Date(),"logEvent": 1,"logMessage": "Successo!"})
WriteResult({ "nInserted" : 1 })

> db.getCollection("log_events").insert({"createdAt": new Date(),"logEvent": 1,"logMessage": "Successo!"})
WriteResult({ "nInserted" : 1 })

Após a inserção dos documentos irei criar um índice TTL na coluna createdAt com a opção expireAfterSeconds de 60 segundos.

> db.getCollection("log_events").createIndex({"createdAt": 1}, {expireAfterSeconds: 60})
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}

Logo a seguir, se fizermos uma pesquisa ordenado pelo campo createdAt de forma descendente na collection log_events, irei verificar que os 3 documentos ainda existem.

> db.getCollection("log_events").find().sort({"createdAt": -1})

{ "_id" : ObjectId("5e6648604c6b3ab44b007757"), "createdAt" : ISODate("2020-03-09T13:45:04.164Z"), "logEvent" : 1, "logMessage" : "Successo!" }
{ "_id" : ObjectId("5e6648254c6b3ab44b007756"), "createdAt" : ISODate("2020-03-09T13:44:05.380Z"), "logEvent" : 1, "logMessage" : "Successo!" }
{ "_id" : ObjectId("5e6647e64c6b3ab44b007755"), "createdAt" : ISODate("2020-03-09T13:43:02.564Z"), "logEvent" : 1, "logMessage" : "Successo!" }

No minuto seguinte, ao realizar novamente a mesma pesquisa podemos perceber que apenas o documento com horário de 13:45 ainda existe e que no próximo minuto 13:46 ele também deixará de existir.

> db.getCollection("log_events").find().sort({"createdAt": -1})
{ "_id" : ObjectId("5e6648604c6b3ab44b007757"), "createdAt" : ISODate("2020-03-09T13:45:04.164Z"), "logEvent" : 1, "logMessage" : "Successo!" }

Caso precisemos alterar o índice para que o expurgo seja realizado em uma frequência diferente como por exempo mensal, bastará dropar o índice atual e criar um novo especificando expireAfterSeconds para um 1 mês em segundos: 24 x 3600 x 30 = 2592000 segundos.

> db.getCollection("log_events").createIndex({"createdAt": 1}, {expireAfterSeconds: 2592000})

MongoDB - Um pouco sobre log de alerta

Olá,

Como todo banco de dados, O MongoDB também tem um log de erros e de informações que são úteis para monitoração e resolução de problemas. O caminho desse log é configurável durante o startup do MongoDB e geralmente tem o nome de mongo.log.

Segue abaixo o padrão utilizado nas mensagens que aparecem no arquivo de log do MongoDB:

[timestamp] [severity] [component] [context] [message]

Em relação ao item severidade (severity) temos os seguintes grupos:

Em relação aos componentes (component) temos as seguintes classes:

• Access:  access control
• Command: database commands
• Control: control activities
• FTDC: diagnostic data collection activities
• Geo:  parsing geospatial shapes
• Index: indexing operations
• Network: network activities
• Query: queries
• REPL: replica sets
• REPL_HB: replica sets heartbeats
• Rollback: rollback db operations
• Sharding: sharding
• Storage: storage activities
• Journal: journal activities
• Write: db write operations

Em relação ao contexto (context), geralmente ela vem acompanhada das informações de Thread e ID de conexão de uma sessão do MongoDB. Outras informações podem ser o valor [initandlisten]. Mensagens no log referente a qualquer nova conexão realizada na instância do MongoDB terá o valor de contexto como [initandlisten] e para as demais outras mensagens as mesmas serão acompanhadas da Thread ou ID de conexão conforme demonstrado a seguir.

2020-02-07T13:06:29.731+0000 [initandlisten] connection accepted from 127.0.0.1:27017 #1000 (13 connections now open)
2020-02-07T13:06:35.770+0000 [conn1000] end connection 127.0.0.1:27017 (12 connections now open)

Exemplo de uma mensagem completa de uma parte do log:
 

2020-02-07T13:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

Timestamp: 2020-02-07T13:28:32.450-0500
Severity: I
Component: NETWORK
Context: [initandlisten]
Message: waiting for connections on port 27017

Segue abaixo exemplos das mensagens mais comuns que podemos ser encontradas no arquivo  de log do MongoDB:

2020-02-07T13:19:46-0300 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
Resolução: Criar o usuário Admin no banco de dados Admin

2020-02-07T13:20:46-0300 E COMMAND  [initandlisten] ** ERROR: getMore command failed. Cursor not found
Resolução: Remover a opção de timeout do cursor db.collection.find(query).noCursorTimeout() ou aumente o limite de tempo db.adminCommand( { setParameter: 1, cursorTimeoutMillis: 600000 } )

2020-02-07T13:21:46-0300 E INDEX  [initandlisten] ** ERROR:E11000 duplicate key error index: db01.customer.$cod.id_1 dup key: { : null }
Resolução: Se refere a violação de uma unique constraint. Tente inserir um documento com um valor de chave diferente para o campo em questão

2020-02-07T13:22:46-0300 E NETWORK  [initandlisten] ** ERROR:Timed out connecting to localhost:27017.
Resolução: A latência entre o driver cliente e o servidor é muito grande. Aumente o valor da opção connectionTimeout na string de conexão.

2020-02-07T13:23:46-0300 E WRITE  [initandlisten] ** ERROR: A write operation resulted in an error. E11000 duplicate key error index: db01.customer.$_id_ dup key: { : 0 }
Resolução: Remova o documento _id duplicado ou insira um documento com outro _id

2020-02-07T13:24:46-0300 E NETWORK  [initandlisten] ** ERROR: No connection could be made because the target machine actively refused it 127.0.0.1:27017 at System.Net.Sockets.Socket.EndConnect
Resolução: O servidor não estpa rodando na porta padrão 27017 ou utilize uma porta diferente.

2020-02-07T13:25.505-0300 I INDEX    [conn4904867] add index fails, too many indexes for db01.customer key:{ cus_status: 1 }
Resolução: Cada collection no MongoDB pode ter no máximo 64 índices. Remova índices que não estão sendo utilizados.

MySQL - Apresentação/Curso

Olá,
 

Neste mês irei compartilhar uma apresentação/curso de MySQL 5.7 que ministrei há algum tempo atrás para uma equipe de DBAs.

Agenda
 
• History
• Download / Install
• Configuration
• Users / Privileges
• Instance Structures / Engines
• InnoDB vs. MyISAM
• Transaction Isolation Level
• Locks
• Binary Log
• CSV Files
• Exporting / Importing (Logical backup)
• COLD / HOT Backup (Physical backup)
• Events (Jobs)
• Performance Tuning
• MySQL in the CLOUD