As a DBA you sometimes have to take time to look for tricks to accomplish tasks that seem simple at first glance. A few days ago, I was asked to identify tables that had sequences prefixed by the schema name as a default value in the columns. You may think: it’s an easy task, just filter on the “data_default” column of the “dba_tab_columns” view, but unfortunately it’s not that simple using SQLPlus. The “data_default” column is in “long” datatype, so you cannot include it directly in the “where” clause of a query.Continue reading “Simulate a where clause on a “long” type column from SQLPlus”
It’s been a while since my last post!
Today, I wanted to share with you some useful commands to extract information from Exadata (product name, serial numbers, …).
This can be helpful for the opening of an new SR for example, or for inventorying components in a CMDB.
Here is the list of interesting elements that can be extracted (the list is not exhaustive, but these are the ones I use most often):
– Exadata product name
– Exadata rack serial number
– Compute nodes and cell nodes serial number
– Compute nodes and cell nodes internal component’s serial number
– Inifiniband switches serial number
– Cisco switch serial number
– PDU’s serial number
Today, I just want to share with you a little script that I use, which allows me to quickly check if my database services are running on the configured “Preferred instances” in RAC environments.Continue reading “Do my database services run on the preferred instance (s)?”
Today, I want to clarify an important point about users authentication in a MongoDB sharded cluster because this seems to be misunderstood by some people.
In a such environment, there are two notions to understand about user authentication, especially when you are DBA:
- cluster authentication, that is, the authentication made when connected trough a “mongos” process.
- local authentication, that is, the authentication made when connected locally on a shard trough a “mongod” process.
A few days ago, I was asked to find a way to automate the addition of newly created Linux virtual machines and databases in our EM13c console. Of course, no action should be performed via the EM web interface!
For the first part (installing the EM13c agent on newly created virtual machines), it’s quite simple, because Oracle gives you many methods (for example, “agent pull” method), in order to carry out this task. But the second part seemed more delicate according to the documentation and my constraints: everything must be done on the virtual machine. I am not allowed to connect to the EM server using SSH.
Fortunately, there is a simple solution that only requires a few extra lines in your shell script!
As a production DBA, you can fall into a situation where you have to act on an environment you do not know.
It can be very difficult to understand how the architecture was designed, but if you know the right commands, you can get a quick overview and all the information you need to start working.
Today, I’m going to give you these basic commands that will help you understand how an Elasticsearch installation was performed on an RHEL system.
When developing shell scripts, it is common usage to check the exit code of a command in order to check if its execution was successful or not. It is pretty easy when you execute only one command, because the exit code can be find using the special parameter “$?”. But if you use pipelines (“command1 | command2 | …”), it is not that simple because “$?” will only give you the exit code of the last command of your pipeline.
So, today, I’m going to show you how to get the exit code for each command in a pipeline. Unfortunately, this only works in bash.
“Sometimes shit happens”. That’s what I thought when I realized that I had lost all the control files of one of my test databases. Of course, I had no backup because “it’s just a test database”…
Fortunately, I only lost my control files but no datafiles or redo log files. This is a very important point because if you are in this situation, all is not lost!
So today, I will show you how you can recover your Oracle database after the loss of all control files.
Today, I’m going to share with you a simple SQL query that will allow you to quickly extract useful information from your OEM repository about your databases:
- Database name
- Database version
- Server name
- Server OS
- OS version
The query can be very useful if you need to fill in a new CMDB for example.
One possible area of improvement when you encounter bottlenecks when inserting or updating in MongoDB is to limit the number of indexes on your collections.
Even though indexes are good for queries against collections, they add an extra step when inserting or updating, which may take some time. Given this fact, it may be wise to delete unused indexes.
So, today, I’m going to give you a Mongo shell script that I use to get statistics on indexes usage for all collections on a MongoDB instance and to identify those that are not used.