Test ability to query MongoDB - testing

In a SQL database, you might run a query like select 1 just to verify that you have a good connection to the database without needing to know anything about the contents of the database or even have permission to access anything in it. Is there a similar sort of query I can run in MongoDB, say against a database with no collections?

You can do it in many ways :
1.Run a basic info command about the database :
db.stats()
db.serverStatus()
http://www.mongodb.org/display/DOCS/Monitoring+and+Diagnostics#MonitoringandDiagnostics-mongoShellDiagnosticCommands
2- Run a mongoDb equivalent of mysql's 'show databases' or 'show tables'
'show dbs'
or
'use myDb'
'show collections'

The easiest way it's running ping command. And it's preferred way to verify connection with the database.
Reading stats or listing dbs is a good way to do it as well, but the result can be nondeterministic (and I am not sure how it would work with different permissions).
https://docs.mongodb.com/manual/reference/command/ping/

Related

How to add Database to default server in Postgres, if all databases are deleted?

I ran and new node application that used a Postgres SQL server. It created a default database called postgres and I wanted to remove it.
I used the below command and close the connection and was able to remove that database.
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'postgres';
Now the pgAdmin looks like the below image.
I am not sure how to add a database again here. It always gives me errors while adding a new server that Database "postgres" does not exist. Any ideas or search query to google about this issue?
I am tempted to say that if you are randomly deleting system databases without first researching if they are needed, you deserve what you get. But while it is customary to leave the postgres database as default database for tools to connect to, it is certainly not forbidden to drop it.
The solution in your case is probably to reconfigure your pgAdmin connection to use template1 instead of postgres as "maintenance database". The only problem with that (and the main reason why the postgres database was introduced) is that it will prevent you from creating new databases with template1 as the (default) template if others are connected to that database as well.
You are connecting as user "postgres" and the default database name it will try is also "postgres". You should be able to specify a different database in the pgadmib settings though. Try "template0" and connect to that to create a new db.

Migrate data from SQL Server to PostgreSQL

I have a stored procedure function as well as table in the SQL Server enterprise 2014. I also have data in the table. Now I need same table and data in PostgreSql(pgAdmin4).
Can anyone suggest to me the idea to migrate data to POSTGRESQL or any idea on creating the SQL script so that I can use psql to run the script?
Depending on how much data you have, you could script out the table and data. Then you could tweak the script as needed for PostgreSQL:
Right click on the SQL database > Tasks > Generate Scripts
On the "Choose Objects" screen, select your specific table then select "Next>"
On the "Set Scripting Options" screen, select "Advanced"
Find the option called "Types of data to script", then select "Schema and data" and select "OK"
Set the filename and continue through the dialog until the file is generated
Tweak the sql script for any specific PostgreSQL syntax
If there is a larger amount of data, you might look into some type of data transfer tool like SSIS.
Exporting the table structure and data as Josh Jay describes will likely require some fixes where the syntax doesn't match, but it should be doable if not tedious. Luckily there are existing conversion tools available to help.
You could also try using a foreign data wrapper to map the tables in SQL Server to a running instance of PostgreSQL. Then it's just a matter of copying tables. Depends on your needs and where each database server is located relative to one another.
The stored procedures will be far more difficult to handle unfortunately. While Oracle's pl/sql language is substantially similar to PostgreSQL's pl/pgsql, MS SQL Server/Sybase's TransactSQL dialect on the other hand is different enough to require rewrites. If the TransactSQL functions also access .Net objects, the migration task may end up far more difficult as you reimplement dependencies or find logical equivalents.

Executing T-sql query from hard drive

I have T-SQL queries stored on a hard drive: I:\queries\query1.sql and I:\queries\query2.sql.
I usually work in a way that I execute a query from a drive, and then I copy results into Excel, and then I work on it.
My problem here is that query1.sql is already long, and now I would like to extend it by getting a result of query2.sql, and join it with a result of query1.sql.
What I could do is appending a code from query2.sql to query1.sql. But then the query is getting really long and hard to maintain.
I would like to do something like this:
SELECT * FROM ("Result of I:\queries\query1.sql") q1
LEFT JOIN ("Result of I:\queries\query2.sql") q2 ON q1.ID=q2.ID
Is there any way to write a query or stored procedure, which will be again stored on a drive to do this?
Basically, you need to ask your DBA for a database when you are able to store things in the database. This can be on the same system where the data is stored. Or, it could be on a linked system. Gosh, you could run SQL Server locally and store the information and data there.
Then, the queries that you are storing in files should be views in the database. You can then run the queries and store and combine the results locally.
You are essentially recreating database functionality using text files and data files -- going through a lot of effort when SQL Server already supports this functionality.
To expand on Gordon's comment (+1), why are you running scripts off of a drive? Most DBA's I've known would treaten bodily harm over this as executing code that they can't control / troubleshoot / see source code control on brings a whole host of security and supportability issues.
Far better to store this code in a Stored Procedure, which will have a saved query execution plan, can be tracked using various DMV's, and have permissions assigned to it, then your outside Excel doc can just set a connection and execute the SP.

How to execute a SQL statement between two separate MySQL connections?

All, is there any means by which it is possible to connect to two separate MySQL databases and execute SQL statements to interact with both?
The aim would be to query DB 1 on connection 1 and insert the results into DB 2 on connection 2.
Is it possible to do this using the MySQL query browser?
I suppose there are two ways how to do this.
the first is manual : DB dump : " SELECT * INTO OUTFILE 'authors090308.sql' FROM authors; " and then "LOAD DATA INFILE 'authors090308.sql' INTO TABLE authors;" (you also need to specify some other parameters as to delimiting columns etc.) or by some other "database dump", where data goes into file the way you want. In between you must switch database manually to the second one.
the second is programmatic : with programming language : Then you need to just open two connections to the databases and realize the statements you need. I don't know if it is what you mean, you'd need to be more specific.
Anyway, you need a connection to a DB server, either via mysql client, oracle sql developer, mysql workbench or via mysql adapter/driver of a programming language. What you need, is the "glue" between 2 connections, which is the programming language. It's either a programming language or a file data is dumped into and back again.
I'm sorry but I don't thing there are any other ways of doing this...as to the first way, you can only get the output from a database and either use mysql pager and pipe the output somewhere (a file perhaps), or SELECT * INTO OUTFILE, mysqldump, mysqlhotcopy etc.

How to determine an Oracle query without access to source code?

We have a system with an Oracle backend to which we have access (though possibly not administrative access) and a front end to which we do not have the source code. The database is quite large and not easily understood - we have no documentation. I'm also not particularly knowledgable about Oracle in general.
One aspect of the front end queries the database for a particular set of data and displays it. We have a need to determine what query is being made so that we can replicate and automate it without the front end (e.g. by generating a csv file periodically).
What methods would you use to determine the SQL required to retrieve this set of data?
Currently I'm leaning towards the use of an EeePC, Wireshark and a hub (installing Wireshark on the client machines may not be possible), but I'm curious to hear any other ideas and whether anyone can think of any pitfalls with this particular approach.
Clearly there are many methods. The one that I find easiest is:
(1) Connect to the database as SYS or SYSTEM
(2) Query V$SESSION to identify the database session you are interested in.
Record the SID and SERIAL# values.
(3) Execute the following commands to activate tracing for the session:
exec sys.dbms_system.set_bool_param_in_session( *sid*, *serial#*, 'timed_statistics', true )
exec sys.dbms_system.set_int_param_in_session( *sid*, *serial#*, 'max_dump_file_size', 2000000000 )
exec sys.dbms_system.set_ev( *sid*, *serial#*, 10046, 5, '' )
(4) Perform some actions in the client app
(5) Either terminate the database session (e.g. by closing the client) or deactivate tracing ( exec sys.dbms_system.set_ev( sid, serial#, 10046, 0, '' ) )
(6) Locate the udump folder on the database server. There will be a trace file for the database session showing the statements executed and the bind values used in each execution.
This method does not require any access to the client machine, which could be a benefit. It does require access to the database server, which may be problematic if you're not the DBA and they don't let you onto the machine. Also, identifying the proper session to trace can be difficult if you have many clients or if the client application opens more than one session.
Start with querying Oracle system views like V$SQL, v$sqlarea and
v$sqltext.
Which version of Oracle? If it is 10+ and if you have administrative access (sysdba), then you can relatively easy find executed queries through Oracle enterprise manager.
For older versions, you'll need access to views that tuinstoel mentioned in his answer.
Same data you can get through TOAD for oracle which is quite capable piece of software, but expensive.
Wireshark is indeed a good idea, it has Oracle support and nicely displays the whole conversation.
A packet sniffer like Wireshark is especially interesting if you don't have admin' access to the database server but you have access to the network (for instance because there is port mirroring on the Ethernet switch).
I have used these instructions successfully several times:
http://www.orafaq.com/wiki/SQL_Trace#Tracing_a_SQL_session
"though possibly not administrative access". Someone should have administrative access, probably whoever is responsible for backups. At the very least, I expect you'd have a user with root/Administrator access to the machine on which the oracle database is running. Administrator should be able to login with a
"SQLPLUS / AS SYSDBA" syntax which will give full access (which can be quite dangerous). root could 'su' to the oracle user and do the same.
If you really can't get admin access then as an alternative to wireshark, if your front-end connects to the database through an Oracle client, look for the file sqlnet.ora. You can set trace_level_client, trace_file_client and trace_directory_client and get it to log the Oracle network traffic between the client and database server.
However it is possible that the client will call a stored procedure and retrieve the data as output parameters or a ref cursor, which means you may not see the query being executed through that mechanism. If so, you will need admin access to the db server, and trace as per Dave Costa's answer
A quick and dirty way to do this, if you can catch the SQL statement(s) in the act, is to run this in SQL*Plus:-
set verify off lines 140 head on pagesize 300
column sql_text format a65
column username format a12
column osuser format a15
break on username on sid on osuser
select S.USERNAME, s.sid, s.osuser,sql_text
from v$sqltext_with_newlines t,V$SESSION s
where t.address =s.sql_address
and t.hash_value = s.sql_hash_value
order by s.sid,t.piece
/
You need access those v$ views for this to work. Generally that means connecting as system.