Sunday, May 28, 2017

To remove a single line from history

If we have already run a command, and want to remove it from history, firstly we will have to use
history
to display the list of commands of history. Then we will have to find the number next to the one we want to delete (e.g. 4321) and run
history -d 4321

Tuesday, May 23, 2017

Installing python cx_oracle on Ubuntu


cs_oracle is the python interface to oracle. To install this to your ubuntu environment, we can follow the below steps:


Step 1:
       sudo apt-get install build-essential unzip python-dev libaio-dev

Step 2:
Click here to download the appropriate zip files required for this. You'll need:

instantclient-basic-linux
instantclient-sdk-linux

Get the appropriate version for your system.. x86 vs 64 etc. Make sure you don't get version 12, since it's not supported by the cx_Oracle moduel yet.

Unzip the content in the same location, so you'll end up with a folder named: instantclient_11_2 which will contain a bunch of .so and jar files.

For my case I used,  $ORACLE_INST_CLIENT, which will basically point to the location where you unzipped your installclient folders.

export ORACLE_INST_CLIENT=$(pwd)/instantclient_11_2

Step 3:
create a symlink to your SO file.

cd $ORACLE_HOME
ln -s libclntsh.so.11.1   libclntsh.so  #the version number on your .so file might be different

Step 4: 
Update your /etc/profile or your ~/.bashrc

export ORACLE_INST_CLIENT=/location/of/your/files/instantclient_11_2
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_INST_CLIENT

Step 5: 
Edit /etc/ld.so.conf.d/oracle.conf

This is a new file, simple add the location of your .so files here, then update the ldpath using

sudo ldconfig

Step 6:
Finally just install cx_oracle module:

pip install cx_oracle



Knowledge Bank:♔
Mastering oracle python
Insert Crud using cx_oracle





Monday, May 22, 2017

Session Trace to find the reason in Oracle DB

Sometimes the same query that ran earlier with less time may take much more time now. To find out the reason, we can follow the below steps.

To find out what is happening you need to do a session trace of a session running this SQL.

  • Open up SQL*Plus and connect to your database.
  • Enable timed statistics if it not already enabled.


alter session set time_statistics=true;


  • Turn on a level 8 SQL Trace of your session. A level 8 trace will capture your wait events. The alter session set events statement below is what enables the SQL Trace of your session.


alter session set tracefile_identifier='Target_Trace';
alter session set events '10046 trace name context forever, level 8';


  • Run your Select and then exit SQL*Plus.



  • On your database server, go to the $UDUMP directory and find your trace file. It will have 'EMP_Select' as part of the name.

  • Using your trace file as input use the tkprof utility to format your trace file into a more readable format. If you invoke tkprof with no arguments, it will give you a help screen with the valid options to use. Make sure you specify the EXPLAIN_PLAN and WAITS=YES options.


Using the output of the TKProf utility you should be able to identify the problem. You would need to especially review the Wait events and Explain plan output.

Monday, May 1, 2017

Tips for Writing Your Research Proposal


1. Know yourself: Know your area of expertise, what are your strengths and what are your weaknesses. Play to your strengths, not to your weaknesses. If you want to get into a new area of research, learn something about the area before you write a proposal. Research previous work. Be a scholar.
.
2. Know the program from which you seek support: You are responsible for finding the appropriate program for support of your research. 
.
3. Read the program announcement: Programs and special activities have specific goals and specific requirements. If you don’t meet those goals and requirements, you have thrown out your chance of success. Read the announcement for what it says, not for what you want it to say. If your research does not fit easily within the scope of the topic areas outlined, your chance of success is nil.
.
4. Formulate an appropriate research objective: A research proposal is a proposal to conduct research, not to conduct development or design or some other activity. Research is a methodical process of building upon previous knowledge to derive or discover new knowledge, that is, something that isn’t known before the research is conducted. 
.
5. Develop a viable research plan: A viable research plan is a plan to accomplish your research objective that has a non-zero probability of success. The focus of the plan must be to accomplish the research objective.
.
6. State your research objective clearly in your proposal: A good research proposal includes a clear statement of the research objective. Early in the proposal is better than later in the proposal. The first sentence of the proposal is a good place. A good first sentence might be, “The research objective of this proposal is...” Do not use the word “develop” in the statement of your research objective. 
.
7. Frame your project around the work of others: Remember that research builds on the extant knowledge base, that is, upon the work of others. Be sure to frame your project appropriately, acknowledging the current limits of knowledge and making clear your contribution to the extension of these limits. Be sure that you include references to the extant work of others. 
.
8. Grammar and spelling count: Proposals are not graded on grammar. But if the grammar is not perfect, the result is ambiguities left to the reviewer to resolve. Ambiguities make the proposal difficult to read and often impossible to understand, and often result in low ratings. Be sure your grammar is perfect. 
.
9. Format and brevity are important: Do not feel that your proposal is rated based on its weight. Use 12-point fonts, use easily legible fonts, and use generous margins. Take pity on the reviewers. Make your proposal a pleasant reading experience that puts important concepts up front and makes them clear. Use figures appropriately to make and clarify points, but not as filler. 
.
10. Know the review process: Know how your proposal will be reviewed before you write it. Proposals that are reviewed by panels must be written to a broader audience than proposals that will be reviewed by mail. Mail review can seek out reviewers with very specific expertise in very narrow disciplines. 
.
11. Proof read your proposal before it is sent: Many proposals are sent out with idiotic mistakes, omissions, and errors of all sorts. Proposals have been submitted with the list of references omitted and with the references not referred to. Proposals have been submitted to the wrong program. Proposals have been submitted with misspellings in the title. These proposals were not successful. Stupid things like this kill a proposal. It is easy to catch them with a simple, but careful, proof reading. Don’t spend six or eight weeks writing a proposal just to kill it with stupid mistakes that are easily prevented.
.
12. Submit your proposal on time: Duh? Why work for two months on a proposal just to have it disqualified for being late? Remember, fairness dictates that proposal submission rules must apply to everyone. It is not up to the discretion of the program officer to grant you dispensation on deadlines. Get your proposal in two or three days before the deadline.