As well as /etc/profile which others have mentioned, some Linux systems now use a directory /etc/profile.d/; any .sh files in there will be sourced by /etc/profile. It's slightly neater to keep your custom environment stuff in these files than to just edit /etc/profile.

You can add it to the file .profile or your login shell profile file (located in your home directory).

To change the environmental variable "permanently" you'll need to consider at least these situations:

1. Login/Non-login shell
2. Interactive/Non-interactive shell

bash

1. Bash as login shell will load /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in the order
2. Bash as non-login interactive shell will load ~/.bashrc
3. Bash as non-login non-interactive shell will load the configuration specified in environment variable $BASH_ENV

$EDITOR ~/.profile
#add lines at the bottom of the file:  
     export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
     export ORACLE_HOME=/usr/lib/oracle/11.2/client64

zsh

$EDITOR ~/.zprofile
#add lines at the bottom of the file:  
     export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
     export ORACLE_HOME=/usr/lib/oracle/11.2/client64

fish

set -Ux LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
set -Ux ORACLE_HOME /usr/lib/oracle/11.2/client64

ksh

$EDITOR ~/.profile
#add lines at the bottom of the file:  
     export LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib
     export ORACLE_HOME=/usr/lib/oracle/11.2/client64

bourne

$EDITOR ~/.profile
#add lines at the bottom of the file:  
     LD_LIBRARY_PATH=/usr/lib/oracle/11.2/client64/lib     
     ORACLE_HOME=/usr/lib/oracle/11.2/client64
     export LD_LIBRARY_PATH ORACLE_HOME

csh or tcsh

$EDITOR ~/.login
#add lines at the bottom of the file:  
     setenv LD_LIBRARY_PATH /usr/lib/oracle/11.2/client64/lib
     setenv ORACLE_HOME /usr/lib/oracle/11.2/client64

If you want to make it permanent for all users, you can edit the corresponding files under /etc/, i.e. /etc/profile for Bourne-like shells, /etc/csh.login for (t)csh, and /etc/zsh/zprofile and /etc/zsh/zshrc for zsh.

Another option is to use /etc/environment, which on Linux systems is read by the PAM module pam_env and supports only simple assignments, not shell-style expansions. (See Debian's guide on this.)

These files are likely to already contain some assignments, so follow the syntax you see already present in your file.

Make sure to restart the shell and relogin the user, to apply the changes.

If you need to add system wide environment variable, there's now /etc/profile.d folder that contains sh script to initialize variable.
You could place your sh script with all you exported variables here.
Be carefull though this should not be use as a standard way of adding variable to env on Debian.

You should use the approaches in attempt 3 or 4, but you need to export the variable; change

MYVAR=123

to

export MYVAR=123

/etc/profile (and hence /etc/profile.d) is read for login shells. sudo su other_user does not run a login shell. It is a bad practice, it leaves the environment contaminated with variables from the original user. You should do either of these commands instead:

sudo -iu other_user
sudo su - other_user

Both of these load /etc/profile because they start login shells, and both start with relatively clean environments.

Ideally, though, the variables should be set in /etc/environment if possible. That file should be read by su, so variables there would be available irrespective of whether a login shell is started. However, that file doesn't support shell syntax, so if you need complex shell code to set your variables, you can't use it.

You have to put the declaration in the initialization files of your shell:

• If you are using bash, ash, ksh or some other Bourne-style shell, you can add

  ABC="123"; export ABC
  

  in your .profile file (${HOME}/.profile). This is the default situation on most Unix installations, and in particular on Debian.

  If your login shell is bash, you can use .bash_profile (${HOME}/.bash_profile) or .bash_login instead.

  Note: If either of these files exists and your login shell is bash, .profile is not read when you log in over ssh or on a text console, but it might still be read instead of .bash_profile if you log in from the GUI. Also, if there is no .bash_profile, then use .bashrc.

• If you've set zsh as your login shell, use ~/.zprofile instead of ~/.profile.

• If you are using tcsh, add

  setenv ABC "123"
  

  in .login file (${HOME}/.login)

• if you are using another shell look at the shell manual how to define environment variables and which files are executed at the shell startup.

Environments for shells

Essentially, anything that runs processes will tend to read a configuration file on starting up, and to affect the environment of that, you need to hit its configuration file.

For user shells, "obvious" places are .profile, .bashrc, .bash_profile (I think) and maybe a couple of others I don't remember. Obviously, more and others if you use zsh, csh, tcsh or whatever as a shell.

There are initialization files read by your windowing environment, which may be either KDE or Gnome. The particular window manager you run underneath that may also read a config file. I admit I don't know the names of those files even for my own installation.

Finally, there are usually "master" configuration files for all those environments somewhere in /etc. They provide defaults for stuff the users don't.

I think that programs that install themselves conscientiously check the various possibilities. Various Linux distributions may offer some helper scripts for this.

cron

This one is a lot easier. For security reasons, cron only passes a couple of environment variables to subprocesses, ALWAYS. I think USER is one of those, and MAILTO another. As far as I know, there's no PATH set - this often annoys newbies. The environment of a cron job is completely different from your shell environment! Anything you want in the environment, you either pass in on the command line in crontab, or you start up a script and let that set up whatever environment it needs.

You can put the variable assignments in one of the shell startup scripts:

/etc/profile
/etc/bash_profile
/etc/bashrc

for bash and some other shells, depending on how your particular distro is configured. There are equivalents for most shells. There is also a file

/etc/environment 

which is not a script but contains enviroment variable assignments, and is loaded at login via pam_env.so. Obviously this works only on systems that use PAM for authentication (almost all Linux distros, but probably not Solaris).

To set variable only for current shell:

VARNAME="my value"

To set it for current shell and all processes started from current shell:

export VARNAME="my value"      # shorter, less portable version

To set it permanently for all future bash sessions add such line to your .bashrc file in your $HOME directory.

To set it permanently, and system wide (all users, all processes) add set variable in /etc/environment:

sudo -H gedit /etc/environment

This file only accepts variable assignments like:

VARNAME="my value"

Do not use the export keyword here.

Use source ~/.bashrc in your terminal for the changes to take place immediately.

Perhaps you are testing in a non-interactive shell. For interactive shells, both /etc/profile and /etc/bash.bashrc are sourced, but for non-interactive shells, only /etc/bash.bashrc is sourced. You might try putting your variables in that file.

/etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile and related files on other shells are discussed at length in this answer.