Olá,
O Oracle Client 21c já está disponível para download para as plataformas Linux.
terça-feira, 15 de dezembro de 2020
sexta-feira, 13 de novembro de 2020
MySQL - Esqueci a senha do root. Como resetar?
Olá,
Abaixo é possível verificar que a autenticação falhou pelo fato de eu ter esquecido a senha do root para conectar no MySQL.
[root@linux ~]# mysql -uroot -psenha
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Segue abaixo o roteiro que deverá ser seguido para que a senha do root seja resetada para uma nova senha.
[root@linux ~]# systemctl stop mysqld
[root@linux ~]# systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"
[root@linux ~]# systemctl start mysqld
[root@linux ~]# mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.28 MySQL Community Server (GPL)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use mysql
Database changed
mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'senha';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
[root@linux ~]# systemctl stop mysqld
[root@linux ~]# systemctl unset-environment MYSQLD_OPTS
[root@linux ~]# systemctl start mysqld
[root@linux ~]# mysql -uroot -psenha
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.28 MySQL Community Server (GPL)
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
quinta-feira, 17 de setembro de 2020
MongoDB - Obtendo informações das collections de um banco de dados
Olá,
Neste artigo irei demonstrar através de um script como obter informações de cada collection de um banco de dados, tais como quantidade de documentos, tamanho total real em MB e o tamanho total em MB ocupado em disco.
mongoPrdSet:PRIMARY> use bd01
switched to db bd01
mongoPrdSet:PRIMARY> cols.forEach(function(col) {
... {
... vstat=db.getCollection(col).stats({ scale : 1024*1024 }) //Em MB
... print(vstat.ns + " - count: " + vstat.count + " - size MB: " + vstat.size + " - storage_size MB: "+vstat.storageSize)
... }
... });
bd01.col01 - count: 2507 - size MB: 139 - storage_size MB: 53
bd01.col02 - count: 44372 - size MB: 2852 - storage_size MB: 600
bd01.col03 - count: 118476 - size MB: 710 - storage_size MB: 155
bd01.col04 - count: 3936 - size MB: 49 - storage_size MB: 16
bd01.col05 - count: 1797 - size MB: 12 - storage_size MB: 3
bd01.col06 - count: 2728 - size MB: 24 - storage_size MB: 5
bd01.col07 - count: 9406 - size MB: 73 - storage_size MB: 14
bd01.col08 - count: 57 - size MB: 32 - storage_size MB: 3
bd01.col09 - count: 1760 - size MB: 62 - storage_size MB: 14
bd01.col10 - count: 1616 - size MB: 38 - storage_size MB: 11
bd01.col11 - count: 1501 - size MB: 64 - storage_size MB: 18
bd01.col12 - count: 42880 - size MB: 4783 - storage_size MB: 1045
bd01.col13 - count: 2652 - size MB: 98 - storage_size MB: 28
bd01.col14 - count: 211 - size MB: 5 - storage_size MB: 1
bd01.col15 - count: 8055 - size MB: 5 - storage_size MB: 1
bd01.col16 - count: 225 - size MB: 14 - storage_size MB: 18
bd01.col17 - count: 309 - size MB: 7 - storage_size MB: 2
bd01.col18 - count: 7579 - size MB: 37 - storage_size MB: 11
bd01.col19 - count: 27762 - size MB: 135 - storage_size MB: 28
bd01.col20 - count: 26807 - size MB: 72 - storage_size MB: 12
segunda-feira, 17 de agosto de 2020
terça-feira, 11 de agosto de 2020
SQL Server - Realizando manutenção nos índices do banco de dados
Olá,
No SQL Server diferentemente do Oracle, temos que nos preocupar em verificar com o tempo a fragmentação dos índices das tabelas. Vale a penas salientar que no SQL Server temos dois tipo de índices que são os mais utilizados - (CLUSTERED INDEX e NONCLUSTERED INDEX). No mais, a fragmentação no SQL Server ocorre quando os índices têm páginas nas quais a ordenação lógica no índice com base no valor de chave do índice não corresponde à ordenação física das páginas de índice. O Mecanismo de Banco de Dados modifica os índices automaticamente sempre que são realizadas operações de entrada, atualização ou exclusão nos dados subjacentes. Por exemplo, a adição de linhas em uma tabela pode fazer com que as páginas existentes nos índices de rowstore sejam divididas para liberar espaço para a inserção de novos valores de chave. No decorrer do tempo, essas modificações podem fazer com que as informações do índice sejam dispersadas pelo banco de dados (fragmentadas). Índices intensamente fragmentados podem prejudicar o desempenho da consulta, porque uma E/S adicional é necessária para localizar dados para os quais o índice aponta. E/S adicionais fazem com que a resposta do aplicativo seja lenta, especialmente quando operações de verificação estão envolvidas. Depois que o grau de fragmentação for conhecido, use a seguinte tabela para determinar o melhor método para remover a fragmentação.
Avg_fragmentation_in_percent Instrução corretiva
--------------------------------- --------------------------------------
> 5% e < = 30% ALTER INDEX REORGANIZE
> 30% ALTER INDEX REBUILD WITH (ONLINE = ON)
Seguindo essa recomendação da Microsoft, costumo utilizar o script abaixo para verificar o grau de fragmentação e realizar a manutenção apropriada (REBUILD ou REORGANIZE). No caso do REORGANIZE, o mesmo pode ser realizado de forma on-line sem prejudicar o desempenho do banco de dados. No caso do REBUILD, caso seja utilizado a versão Enterprise, é melhor adicionar a opção (ONLINE = ON) para não "lockar" a tabela durante a reconstrução do índice.
SELECT distinct (Index_Statement) FROM
(
SELECT CASE WHEN avg_fragmentation_in_percent BETWEEN 5 AND 30 THEN
'ALTER INDEX [' + name + '] ON ' + (SELECT TOP 1 TABLE_SCHEMA FROM
INFORMATION_SCHEMA.TABLES
WHERE
TABLE_NAME = OBJECT_NAME(b.[OBJECT_ID]) AND TABLE_TYPE = 'BASE TABLE')
+ '.[' + OBJECT_NAME(b.[OBJECT_ID]) + '] REORGANIZE;'
WHEN avg_fragmentation_in_percent > 30 THEN
'ALTER INDEX [' + name + '] ON ' + (SELECT TOP 1 TABLE_SCHEMA FROM
INFORMATION_SCHEMA.TABLES
WHERE
TABLE_NAME = OBJECT_NAME(b.[OBJECT_ID]) AND TABLE_TYPE = 'BASE TABLE')
+ '.[' + OBJECT_NAME(b.[OBJECT_ID]) + '] REBUILD;'
END AS Index_Statement
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS a
JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id
WHERE avg_fragmentation_in_percent > 5
AND index_type_desc <> 'HEAP'
AND page_count > 640) index_rebuild_reorganize
WHERE Index_Statement Is NOT NULL;
Index_Statement
----------------------------------------------------
ALTER INDEX [IDX_TBL_08] ON dbo.[TBL_08] REORGANIZE;
ALTER INDEX [IDX_TBL_07] ON dbo.[TBL_07] REBUILD;
ALTER INDEX [IDX_TBL_06] ON dbo.[TBL_06] REORGANIZE;
ALTER INDEX [IDX_TBL_05] ON dbo.[TBL_05] REBUILD;
ALTER INDEX [IDX_TBL_04] ON dbo.[TBL_04] REORGANIZE;
ALTER INDEX [IDX_TBL_03] ON dbo.[TBL_03] REBUILD;
ALTER INDEX [IDX_TBL_02] ON dbo.[TBL_02] REORGANIZE;
ALTER INDEX [IDX_TBL_01] ON dbo.[TBL_01] REORGANIZE;
ALTER INDEX [PKI_TBL_08] ON dbo.[TBL_08] REORGANIZE;
ALTER INDEX [PKI_TBL_09] ON dbo.[TBL_09] REORGANIZE;
(10 rows affected)
Completion time: 2020-08-07T16:24:33.6867313-03:00
segunda-feira, 13 de julho de 2020
MongoDB - Um pouco sobre o db.currentOp()
Olá,
O MongoDB possui função chamada db.currentOp() que retorna todas as
conexões abertas da instância. No comando abaixo irei retornar todas as
conexões que estão realizando operações que estão em execução a mais de 1
segundo. É possível verificar no exemplo abaixo que a conexão conn9145756
proveniente do servidor 192.168.1.10 está realizando uma query no banco bd01
e collection customer através do _id: ObjectId("0000001") com duração de
3 segundos. As demais operações estão ligadas ao namespace local.oplog.rs
que são operações de replicação do MongoDB.
mongoSet:PRIMARY> db.currentOp({"secs_running": {$gte: 1}})
{
"inprog" : [
{
"desc" : "conn9145756",
"threadId" : "139937773053696",
"connectionId" : 9145756,
"client" : "192.168.1.10:34456",
"active" : true,
"opid" : 425355448,
"secs_running" : 3,
"microsecs_running" : NumberLong(7491051),
"op" : "query",
"ns" : "bd01.customer",
"query" : {
"find" : "customer",
"filter" : {
"_id" : ObjectId("0000001")
},
"batchSize" : 300
},
"numYields" : 0,
"locks" : {
"Global" : "r",
"Database" : "r",
"Collection" : "r"
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(2)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(1)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(1)
}
}
}
},
{
"desc" : "ReplBatcher",
"threadId" : "139937860310784",
"active" : true,
"opid" : 10,
"secs_running" : 1300926,
"microsecs_running" : NumberLong("22775762702217"),
"op" : "none",
"ns" : "local.oplog.rs",
"query" : {
},
"numYields" : 0,
"locks" : {
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(2)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(1)
}
},
"oplog" : {
"acquireCount" : {
"r" : NumberLong(1)
}
}
}
},
{
"desc" : "rsSync",
"threadId" : "139938179233536",
"active" : true,
"opid" : 9,
"secs_running" : 1300926,
"microsecs_running" : NumberLong("22775762702158"),
"op" : "none",
"ns" : "local.oplog.rs",
"query" : {
},
"numYields" : 0,
"locks" : {
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(24704),
"w" : NumberLong(18515),
"R" : NumberLong(6172),
"W" : NumberLong(6172)
},
"acquireWaitCount" : {
"W" : NumberLong(974)
},
"timeAcquiringMicros" : {
"W" : NumberLong(19504794)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(8),
"w" : NumberLong(1),
"W" : NumberLong(18514)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(7)
}
},
"Metadata" : {
"acquireCount" : {
"w" : NumberLong(1)
}
},
"oplog" : {
"acquireCount" : {
"r" : NumberLong(1),
"w" : NumberLong(1)
}
}
}
},
{
"desc" : "WT RecordStoreThread: local.oplog.rs",
"threadId" : "139938314262272",
"active" : true,
"opid" : 424925952,
"secs_running" : 920,
"microsecs_running" : NumberLong(920757610),
"op" : "none",
"ns" : "local.oplog.rs",
"query" : {
},
"numYields" : 0,
"locks" : {
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(1),
"w" : NumberLong(1)
}
},
"Database" : {
"acquireCount" : {
"w" : NumberLong(1)
}
},
"oplog" : {
"acquireCount" : {
"w" : NumberLong(1)
}
}
}
}
],
"ok" : 1
}
Caso queiramos filtrar apenas as conexões ativas ignorando operações
internas de replicação, bastará utilizar o exemplo abaixo.
mongoSet:PRIMARY> db.currentOp({"active" : true,"secs_running" : { "$gt" : 0 },"ns" : {$ne : "local.oplog.rs"}})
{
"inprog" : [
{
"desc" : "conn1371708",
"threadId" : "140655653025536",
"connectionId" : 1371708,
"client" : "172.31.80.121:51282",
"active" : true,
"opid" : 2036637847,
"secs_running" : 1,
"microsecs_running" : NumberLong(1082772),
"op" : "query",
"ns" : "bd01.product",
"query" : {
"$msg" : "query not recording (too large)"
},
"numYields" : 58,
"locks" : {
"Global" : "r",
"Database" : "r"
},
"waitingForLock" : true,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(118)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(59)
},
"acquireWaitCount" : {
"r" : NumberLong(58)
},
"timeAcquiringMicros" : {
"r" : NumberLong(935638)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(58)
}
}
}
},
{
"desc" : "conn980301",
"threadId" : "140655740397312",
"connectionId" : 980301,
"client" : "192.168.1.10:55542",
"active" : true,
"opid" : 2036637676,
"secs_running" : 1,
"microsecs_running" : NumberLong(1310312),
"op" : "query",
"ns" : "bd01.product",
"query" : {
"$msg" : "query not recording (too large)"
},
"numYields" : 74,
"locks" : {
"Global" : "r",
"Database" : "r",
"Collection" : "r"
},
"waitingForLock" : false,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(150)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(75)
},
"acquireWaitCount" : {
"r" : NumberLong(71)
},
"timeAcquiringMicros" : {
"r" : NumberLong(1140143)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(75)
}
}
}
},
{
"desc" : "conn980023",
"threadId" : "140655865579264",
"connectionId" : 980023,
"client" : "192.168.1.10:55132",
"active" : true,
"opid" : 2036637864,
"secs_running" : 1,
"microsecs_running" : NumberLong(1071661),
"op" : "query",
"ns" : "bd01.product",
"query" : {
"$msg" : "query not recording (too large)"
},
"numYields" : 63,
"locks" : {
"Global" : "r",
"Database" : "r"
},
"waitingForLock" : true,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(128)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(64)
},
"acquireWaitCount" : {
"r" : NumberLong(60)
},
"timeAcquiringMicros" : {
"r" : NumberLong(910226)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(63)
}
}
}
},
{
"desc" : "conn980300",
"threadId" : "140655781451520",
"connectionId" : 980300,
"client" : "192.168.1.10:44064",
"active" : true,
"opid" : 2036637740,
"secs_running" : 1,
"microsecs_running" : NumberLong(1200164),
"op" : "query",
"ns" : "bd01.product",
"query" : {
"$msg" : "query not recording (too large)"
},
"numYields" : 67,
"locks" : {
"Global" : "r",
"Database" : "r"
},
"waitingForLock" : true,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(136)
}
},
"Database" : {
"acquireCount" : {
"r" : NumberLong(68)
},
"acquireWaitCount" : {
"r" : NumberLong(64)
},
"timeAcquiringMicros" : {
"r" : NumberLong(1015696)
}
},
"Collection" : {
"acquireCount" : {
"r" : NumberLong(67)
}
}
}
}
],
"ok" : 1
}
quarta-feira, 10 de junho de 2020
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)
segunda-feira, 11 de maio de 2020
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 }
segunda-feira, 13 de abril de 2020
MongoDB - Capped Collection
Olá,
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.
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 } )
segunda-feira, 9 de março de 2020
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})
sexta-feira, 7 de fevereiro de 2020
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.
terça-feira, 7 de janeiro de 2020
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
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