What is the age old method of testing execution time of stored procedures on informix 11.5. I am thinking of doing something like this from a unix prompt:
$ time (echo 'execute procedure foo(1)' | dbaccess ...)
Any other ideas?
Sure, you can do something more elaborate, but if that's all you need, why bother? Obviously if there are more steps, move the sql into a separate file and run
time dbaccess <dbname> file.sql
btw, there's a quote missing from your code fragment.
I use my SQLCMD program for this sort of job. It has a benchmark mode (-B option), and also makes it easier to write the SQL:
sqlcmd -d stores -B -e 'execute procedure foo(1)'
It is open source and available from the IIUG Software Archive.
Related
Can anyone please tell me the exact meaning/significance of #forecast2.sql in below query , the given query is a part of one shell script. Also how can I find the exact sql query executed by #forecast2.sql
Below is the code:
sqlplus -s / #forecast2.sql $SCHED_ID > /tmp/BR_forecast
I need to find the sql query that's been executed here.
This means that sqlplus will execute script called forecast2.sql.
You could locate it:
> env | grep SQLPATH
-- path where scripts are located
Looked everywhere... to no avail.
I am trying to do a basic select using SQLCMD from the command line:
sqlcmd -S myServer -d myDB -E
So far so good.
select * from myTable
Nothing, just goes to the next line. Shouldn't it display a table with values ? Or at least "n row(s) returned" ?
I also tried the -o param: it creates an empty file.
When you use the SQLCMD tool in interactive mode statements that you enter are sent to the server when you use the keyword GO.
GO signals both the end of a batch and the execution of any cached
Transact-SQL statements. When specifying a value for count, the cached
statements will be executed count times, as a single batch.
See Use the sqlcmd Utility specifically the section titled Running Transact-SQL Statements Interactively by Using sqlcmd
So in your case:
select * from myTable enter
GOenter
I have the following problem, I need to put in a script that is going to run before the new version is rolled the SQL code that enables the pgAgent in PostgreSQL. However, this code should be run on the maintenance database (postgres) and the database where we run the script file is another one.
I remember that in SQL Server there is a command "use " so you could do something like:
use foo
-- some code
use bar
-- more code
is there something similar in PostgreSQL?
You can put in your file something like:
\c first_db_name
select * from t; --- your sql
\c second_db_name
select * from t; --- your sql
...
Are you piping these commands through the psql command? If so, \c databasename is what you want.
psql documentation
You can't switch databases in Postgres in this way. You actually have to reconnect to the other database.
PostgreSQL doesn't have the USE command. You would most likely use psql with the --dbname option to accomplish this, --dbname takes the database name as a parameter. See this link for details on the other options you can pass in you will also want to check out the --file option as well. http://www.postgresql.org/docs/9.0/interactive/app-psql.html
well after looking on the web for some time I found this which was what I need it
http://www.postgresonline.com/journal/archives/44-Using-DbLink-to-access-other-PostgreSQL-Databases-and-Servers.html
I would like to run some ad hoc select statements in the IBM System I Navigator tool for DB2 using a variable that I declare.
For example, in the SQL Server world I would easily do this in the SQL Server Management Studio query window like so:
DECLARE #VariableName varchar(50);
SET #VariableName = 'blah blah';
select * from TableName where Column = #VariableName;
How can I do something similar in the IBM System I Navigator tool?
I ran across this post while searching for the same question. My coworker provided the answer. It is indeed possible to declare variables in an ad hoc SQL statement in Navigator. This is how it is done:
CREATE OR REPLACE VARIABLE variableName VARCHAR(50);
SET variableName = 'blah';
SELECT * FROM table WHERE column = variableName;
DROP VARIABLE variableName;
If you don't drop the variable name it will hang around until who knows when...
At the moment, we're working on the same issue at work. Unfortunaly, we concluded that this is not possible. I agree, it would be great but it just doesn't work that way. iNavigator doesn't support SET or Define. You can do that in embedded SQL but this is not embedded SQL. Even if you create a separate document (xxx.sql), then need to open this document to run the script what makes it an interactive script (that is, DECLARE SECTION is not allowed).
As an alternative, in the SQL screen/script you can use CL:. Anything after this prefix is executed as CL command. You may manipulate your tables (e.g. RNMF) this way.
As a second alternative, the iSeries does support Rexx scripts (default installed with the os). Rexx is good dynamic script language and it does support embedded SQL. I've done that a lot of times and it works great. I even created scripts for our production environment.
Just create one 'default' script with an example PREPARE and CURSOR statement and copy at will. With that script you can play around. See the Rexx manual for the correct syntax of exec-sql. Also, you do have STDIN and STDOUT but you can use 'OVRDBF' to point to a database table (physical file). Just let me know if you need an example Rexx script.
Notice that the manual "SQL embedded programming" does have Rexx examples.
Here are a couple of other alternatives.
Data Transfer Tool - You can run the iSeries Data Transfer Tool from the command line (RTOPCB). First, run the GUI version and create a definition file. If you edit this file with a text editor, you will see that this is just an old-fashioned INI file and you can easily find the line with the query in it. From there, you could write a batch file or otherwise pre-process the text file to allow you to manipulate the query before submitting it to the query tool.
QSHELL - If you can log on to the iSeries interactively, then you may find the QSHELL environment more familiar than CL or REXX (although REXX is kind of fun). QSHELL is a full POSIX environment running on the iSeries. Use the command STRQSH to start QSHELL. You can have ksh or csh as a shell. Inside QSHELL, there is a command called "db2" that submits queries. So, you should be able to do something like this inside QSHELL:
system> VariableName = 'blah blah'
system> db2 "select * from TableName where Column = \'$VariableName\'"
You may have to fiddle with the quotes to get ksh to pass them correctly.
Also, inside QSHELL, you should have a full Perl installation that will allow you to use DBI to get data.
Some other ways to interact with data on the iSeries: query from the client with Python via ODBC; query from the client with Jython via JDBC; install Jython directly on the iSeries and then query via JDBC.
I have an oracle script that I am trying to convert to valid db2 syntax. Within this sql file I have various calls to other sql files passing in a parameter using the '#' syntax.
e.g.
#script1 param1
#script2 param2
Can anyone help me with valid db2 equivalent statements? Is there an equivalent run command in db2? is it possible to pass parameters to a sql script in db2?
thanks,
smauel
The thing you are after is the DB2 Command Line Processor (CLP).
If you want to execute a script, you would execute in the CLP:
db2 -vtf script1
-f tells the CLP to run command input from the given file.
Here's the full list of options.
Unfortunately db2 doesn't support passing parameters to a script. You would have to combine your db2 -vtf commands with other scripting commands (such as sed) to generate the scripts for you, as in this example.
1) place the filename.sql file in SQLLIB/BIN
2) run db2cmd
3) execute this to connect to the required db
db2 connect to *dbname* user *userid* using *password*
4) excute this command
db2 -vtf *filename.sql*
This should execute the sql statements in the file one by one. The sql statements must be ending with a semicolon
There is an easier way for passing in parameters, that works fine for us (it might not work with (complex) multiline sql statements).
Convert your sql-script into a shell script by adding 'db2 ' at the beginning of each line. Than you can use the standard variable replacement syntax from your shell in your scripts.
so instead of
insert ...
update ...
you will have
db2 insert ...
db2 update ...
Place file in one directory.
Open db2cmd.exe as administrator
Navigate to directory where you have place the script
type db2 -vtf `