[1.8.x] Made assorted improvements to the Oracle documentation.

Backport of 6f1b09bb5c1bafe4633514cbff37f9a7ed7a63ae from master

5 files changed, 28 insertions, 18 deletions

diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt
index ac0e4fff26..2c45246566 100644
--- a/docs/intro/tutorial01.txt
+++ b/docs/intro/tutorial01.txt
@@ -201,8 +201,9 @@ and creates any necessary database tables according to the database settings
 in your :file:`mysite/settings.py` file and the database migrations shipped
 with the app (we'll cover those later). You'll see a message for each
 migration it applies. If you're interested, run the command-line client for your
-database and type ``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), or
-``.schema`` (SQLite) to display the tables Django created.
+database and type ``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), ``.schema``
+(SQLite), or ``SELECT TABLE_NAME FROM USER_TABLES;`` (Oracle) to display the
+tables Django created.
 
 .. admonition:: For the minimalists
 
@@ -518,7 +519,7 @@ Note the following:
 * It's tailored to the database you're using, so database-specific field types
   such as ``auto_increment`` (MySQL), ``serial`` (PostgreSQL), or ``integer
   primary key autoincrement`` (SQLite) are handled for you automatically. Same
-  goes for the quoting of field names -- e.g., using double quotes or 
+  goes for the quoting of field names -- e.g., using double quotes or
   single quotes.
 
 * The :djadmin:`sqlmigrate` command doesn't actually run the migration on your
@@ -565,9 +566,9 @@ but for now, remember the three-step guide to making model changes:
 * Run :djadmin:`python manage.py migrate <migrate>` to apply those changes to
   the database.
 
-The reason that there are separate commands to make and apply migrations is 
-because you'll commit migrations to your version control system and ship them 
-with your app; they not only make your development easier, they're also 
+The reason that there are separate commands to make and apply migrations is
+because you'll commit migrations to your version control system and ship them
+with your app; they not only make your development easier, they're also
 useable by other developers and in production.
 
 Read the :doc:`django-admin documentation </ref/django-admin>` for full
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index a9308a76a0..bad0a06b98 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -762,13 +762,15 @@ for Django's own test suite.
 All of these privileges are included in the DBA role, which is appropriate
 for use on a private developer's database.
 
-The Oracle database backend uses the ``SYS.DBMS_LOB`` package, so your user
-will require execute permissions on it. It's normally accessible to all users
-by default, but in case it is not, you'll need to grant permissions like so:
+The Oracle database backend uses the ``SYS.DBMS_LOB`` and ``SYS.DBMS_RANDOM``
+packages, so your user will require execute permissions on it. It's normally
+accessible to all users by default, but in case it is not, you'll need to grant
+permissions like so:
 
 .. code-block:: sql
 
     GRANT EXECUTE ON SYS.DBMS_LOB TO user;
+    GRANT EXECUTE ON SYS.DBMS_RANDOM TO user;
 
 Connecting to the database
 --------------------------
@@ -892,10 +894,10 @@ some limitations on the usage of such LOB columns in general:
 
 * LOB columns may not be used in a ``SELECT DISTINCT`` list. This means that
   attempting to use the ``QuerySet.distinct`` method on a model that
-  includes ``TextField`` columns will result in an error when run against
-  Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction
-  with ``distinct()`` to prevent ``TextField`` columns from being included in
-  the ``SELECT DISTINCT`` list.
+  includes ``TextField`` columns will result in an ``ORA-00932`` error when
+  run against Oracle. As a workaround, use the ``QuerySet.defer`` method in
+  conjunction with ``distinct()`` to prevent ``TextField`` columns from being
+  included in the ``SELECT DISTINCT`` list.
 
 .. _third-party-notes:
 
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 5c8690f712..a92727abd8 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -217,11 +217,12 @@ Runs the command-line client for the database engine specified in your
 * For PostgreSQL, this runs the ``psql`` command-line client.
 * For MySQL, this runs the ``mysql`` command-line client.
 * For SQLite, this runs the ``sqlite3`` command-line client.
+* For Oracle, this runs the ``sqlplus`` command-line client.
 
 This command assumes the programs are on your ``PATH`` so that a simple call to
-the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in
-the right place. There's no way to specify the location of the program
-manually.
+the program name (``psql``, ``mysql``, ``sqlite3``, ``sqlplus``) will find the
+program in the right place. There's no way to specify the location of the
+program manually.
 
 The :djadminopt:`--database` option can be used to specify the database
 onto which to open a shell.
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index c5f83a7cf4..5dbac1c4ae 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -732,7 +732,7 @@ object. If it's ``None``, Django uses the :ref:`current time zone
 
     .. _pytz: http://pytz.sourceforge.net/
     .. _Time Zones: http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES
-    .. _Choosing a Time Zone File: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1006667
+    .. _Choosing a Time Zone File: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch4datetime.htm#NLSPG258
     .. _mysql_tzinfo_to_sql: http://dev.mysql.com/doc/refman/5.6/en/mysql-tzinfo-to-sql.html
 
 none
@@ -2732,7 +2732,7 @@ SQL equivalents::
 
     SELECT ... WHERE title REGEXP BINARY '^(An?|The) +'; -- MySQL
 
-    SELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'c'); -- Oracle
+    SELECT ... WHERE REGEXP_LIKE(title, '^(An?|The) +', 'c'); -- Oracle
 
     SELECT ... WHERE title ~ '^(An?|The) +'; -- PostgreSQL
 
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index d4f560861f..f52076d2f7 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -23,11 +23,17 @@ able to store certain characters in the database, and information will be lost.
 * PostgreSQL users, refer to the `PostgreSQL manual`_ (section 22.3.2 in
   PostgreSQL 9) for details on creating databases with the correct encoding.
 
+* Oracle users, refer to the `Oracle manual`_ for details on how to set
+  (`section 2`_) or alter (`section 11`_) the database character set encoding.
+
 * SQLite users, there is nothing you need to do. SQLite always uses UTF-8
   for internal encoding.
 
 .. _MySQL manual: http://dev.mysql.com/doc/refman/5.6/en/charset-database.html
 .. _PostgreSQL manual: http://www.postgresql.org/docs/current/static/multibyte.html
+.. _Oracle manual: http://docs.oracle.com/cd/E11882_01/server.112/e10729/toc.htm
+.. _section 2: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch2charset.htm#NLSPG002
+.. _section 11: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#NLSPG011
 
 All of Django's database backends automatically convert Unicode strings into
 the appropriate encoding for talking to the database. They also automatically