Skip to Main Content

Hardware

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

SAM-QFS Tape Library and Drive Support, up to 5.3

Interoperable Peripherals

Golden Rules

  • The combination of a tape library and a tape drive is interoperable with the Sun StorageTek Storage Archive Manager (SAM) if:
    o the library robotic interface is interoperable with SAM
    o the tape drive type is interoperable with SAM
    o the tape drive type is interoperable with the tape library (as defined by the library vendor).
  • The combination of a network attached tape library and drive is interoperable with the Sun StorageTek Storage Archive Manager (SAM) if:
    o The network attached robotic interface is interoperable with SAM
    o The tape drive type is interoperable with SAM
    o The tape library is interoperable with the network attached robotic interface
    (as defined by the library and network attached robotic interface vendor).
    o The tape drive type is interoperable with the tape library (as defined by the library vendor).

Definitions

  • FCS - First Customer Ship of a particular release
  • 4.6 (-04) - Indicates the fourth patch release of the 4.6 FCS
  • Planned - Support planned for a future patch of the current SAM-QFS release within a calendar year

Sun StorageTek

Type Min SAM Version EOL Notes
Oracle SL150 5.2 (-01) NOTE 1: Instructions regarding the manual change required to use the SL150 with SAM-QFS 5.2 Patch 01 and 5.3 are posted here .  With the SAM-QFS 5.3-01 patch, no manual change required.  NOTE 2: Partitioning supported. Each partition must only contain one media type.
StorEdge L7 4.0 (-04)
StorEdge L8 4.0 (-04)
StorEdge L25 4.0 (-02)
StorEdge L100 4.0 (-02)
StorEdge L5500 3.x
StorEdge L6000 3.x
StorEdge L9 4.0 (FCS)
StorEdge L20/L40/L60 4.0 (FCS)
StorEdge L280 4.0 (FCS)
StorEdge L1000 4.0 (FCS)
Sun StorageTek or StorEdge C4
Sun StorageTek or StorEdge L180 3.x
Sun StorageTek SL24 4.6 (-04)
Sun StorageTek SL48 4.6 (-04)
Sun StorageTek or StorEdge SL500 4.3 (FCS) Beginning with SAM-QFS 5.2, partitioning supported. Each partition must only contain one media type.
Sun StorageTek or StorEdge L700 3.x
Sun StorageTek L1400M 4.6 (FCS) Partitioning supported. Each partition must only contain one media type.
Sun StorageTek SL3000 4.6 (-06) Partitioning supported. All possible partitioning modes are qualified. Also beginning with SAM-QFS 5.2, the AEM expansion module of the SL3000 is supported.
Sun StorageTek or StorEdge SL8500 4.1 (FCS) Partitioning Supported. Each partition must only contain one media type.
Sun StorageTek VTL 1.0 4.6 (-04)
Sun StorageTek VTL Plus 2.0 4.6-04
StorageTek VTL Prime 5.2
Sun StorageTek 5800 (1.1) 4.6 (-04)

StorageTek

Type Min SAM Version EOL Notes
STK L20/L40/L80 4.0 (FCS)
STK L180 3.x
STK L700 3.x
STK 9310 3.x
STK SL8500 4.1 (FCS) Supports partitioning
STK TimberWolf 9710 3.x
STK TimberWolf 9714 3.x
STK TimberWolf 9730 3.x
STK TimberWolf 9738 3.x
STK TimberWolf 9740 3.x

Other

Type Min SAM Version EOL Notes
ADIC Scalar 224 3.x
ADIC Scalar 448 3.x
ADIC Scalar 458 3.x
ADIC Scalar 100 4.0 (FCS)
ADIC Scalar 1000 4.0 (FCS) 4.0 (-03): support for network attached
ADIC Scalar 10K 4.0 (-02) 4.0 (-03): support for network attached
ADIC Scalar i2000
ADIC (EMASS) AML/2 3.x
ADIC (EMASS) AML/J 3.x
Ampex DST 410 3.x 4.1 (FCS)
ATL 2/28 3.x
ATL 2/52 3.x
ATL 4/52 3.x
ATL 26/176 3.x
ATL 2640 Series 3.x
ATL 7100 Series 3.x
ATL L200 3.x
ATL L500 3.x
ATL M1500 4.0 (-02)
ATL M2500 4.0 (-02)
ATL P1000 3.x
ATL P4000 4.0 (-02)
ATL P7000 4.0 (-02)
DEC/Quantum DLT 4500 Stacker 3.x
DEC/Quantum DLT 4700 Stacker 3.x
DEC/Quantum DLT 7500 Stacker 3.x
DISC DocuStore Series 3.x
Exabyte 210 3.x
Exabyte 230 D 3.x
Exabyte 215 A 3.x
Exabyte 215 M 3.x
Exabyte 430 A 3.x
Exabyte 430 M 3.x
Fujitsu LT300N M8100 3.x
Fujitsu ETERNUS LT270 and LT250 4.6 (-06)
Grau Data Storage IVD-E 3.x
Grau Data Storage IVD-M 3.x
Grau Data Storage IVD-XL 3.x
Grau Infinistore 4.0 (-02)
HP Magneto-Optical 3.x SPARC only
IBM 3584 3.x The HD frames addition to the TS3500 is supported with
IBM microcode level A420 or greater.
Mountain Gate D-360 Series 3.x
Overland Data LXB 3.x
Overland Data NEO Series 4100 3.x
Plasmon G-Enterprise 4.3 (FCS) SPARC only
Plasmon M20 3.x SPARC only
Plasmon M32 3.x SPARC only
Plasmon M52 3.x SPARC only
Plasmon M104 3.x SPARC only
Plasmon M156 3.x SPARC only
Plasmon M258 3.x SPARC only
Plasmon M500 3.x SPARC only
Qualstar RLS Series 4.2 (FCS)
Qualstar TLS Series 4.3 (FCS)
Quantum/ATL P4000
Quantum/ATL P7000
Quantum PX500
Sony CSM-20S 4.6 (-02)
Sony CSM-60 PetaSite
Sony CSM-100 PetaSite
Sony CSM-200 PetaSite
Sony DMS B9 3.x
Sony DMS B9 3.x
Sony DMS B150L 3.x
Sony DMS 35 3.x
Sony DMS 80L 3.x
Sony DMS-8400 PetaSite 3.x
Spectra Logic 2000 3.x
Spectra Logic 9000 3.x
Spectra Logic 10000S 3.x
Spectra Logic Python Series (T950/380/200/120/T50/T50e) 4.6 (-06)

Interoperable Network Attached Robotic Interfaces

Type Min SAM Version EOL Notes
STK ACSLS 6.0 3.5.0
STK ACSLS 6.1 4.0 (-04)
STK ACSLS 7.0 4.1 (FCS) No support for ACSLS on Linux
4.1 (GA): support for firewall
STK ACSLS 7.1 4.1 (FCS) No support for ACSLS on Linux
Sun StorageTek ACSLS 7.2 4.6 (-04)
Sun StorageTek ACSLS 7.3 4.6 (-06)
StorageTek ACSLS 8.0.2 5.2
StorageTek ACSLS 8.2
5.3
ADIC/Grau DAS 3.12 4.6 (-01), 4.5 (-06) SPARC only
IBM 3494E 3.5.0 SPARC only
Sony DZC-8000S 3.5.0 SPARC only
Quantum i500/i2000/i6000 libraries
5.3-02

Interoperable Tape Drives and Media

Type Min SAM Version EOL WORM Encryption Notes
Ampex DST310 3.x 4.1 (FCS) None None
Ampex DST312, 312S,312L,312M 3.x 4.1 (FCS) None None
Ampex DST314,314L,314M,314S 3.x 4.1 (FCS) None None
Archive Python 3.x None None
Exabyte 8505 3.x None None
Exabyte Mammoth II 3.x None None
HP LTO-1 4.0 (-05) None None
HP LTO-2 4.0 (-05) None None
HP LTO-3 4.3 (FCS) Yes None
HP LTO-4 4.6 (-04) None 5.2 Encryption qualified with StorageTek Crypto KMS 2.0.
HP LTO-4 5.0 (FCS) Yes None
HP LTO-5 5.2 (-01) 5.3 None
HP LTO-6
5.3 (-01)
5.3 (-01)
None
HP Optical 1.3GB 3.x None None SPARC only
HP Optical 2.6GB 3.x None None SPARC only
HP Optical 5.2GB 3.x None None SPARC only
HP Optical 9.1GB 3.x None None SPARC only
IBM 3490 3.x None None
IBM 3490E 3.x None None
IBM 3590 3.x None None
IBM 3590E 3.x None None
IBM 3590H 3.x None None
IBM 3592 J1A None None
IBM 3592 E05 4.6 (FCS) Yes None
IBM 3592 700GB 4.6 (-06) None None
IBM LTO-1 4.0 (-02) None None
IBM LTO-2 4.1 (FCS) None None 4.1.x (GA): requires drive firmware 38D0 or later
IBM LTO-3 4.4 (FCS) Yes None
IBM LTO-4 4.6 (-04) 4.6 (-06) Planned
IBM LTO-5 5.2 (-01) 5.3 None
IBM LTO-6
5.3 (-01)
5.3 (-01)
None
IBM TS1120 4.6 (-06) None None
Plasmon UDO/MO 4.3 (FCS) Yes None SPARC only
Quantum DLT 2000 3.x None None
Quantum DLT 4000 3.x None None
Quantum DLT 7000 3.x None None
Quantum DLT 8000 None None
Quantum Super DLT 220 4.0 None None
Quantum Super DLT 320 4.0 None None
Quantum Super DLT 600 None None
Seagate LTO-1 4.0 (-02) None None
Sony AIT-1 3.x None None
Sony AIT-2 3.x None None
Sony AIT-3 3.x None None
Sony SAIT-1 4.1 (FCS) Yes None
Sony SAIT-2 4.6 (-04) None None
Sony DTF-1 3.x None None
Sony DTF-2 3.x None None
Sony Optical F521 3.x None None SPARC only
Sony Optical F541 3.x None None SPARC only
Sony Optical F551 3.x None None SPARC only
StorageTek LTO-5 5.2 (-01) 5.3 None
Sun StorageTek T9840A 3.x VolSafe None
Sun StorageTek T9840B 4.0 (FCS) VolSafe None
Sun StorageTek T9840C 4.1 (FCS) VolSafe None
Sun StorageTek T9840D 4.6 (-06) Volsafe 5.2 Encryption qualified with StorageTek Crypto KMS 2.0.
Sun StorageTek T9940A 3.x VolSafe None
Sun StorageTek T9940B 4.0 (FCS) VolSafe None
Sun StorageTek T10000A 4.6 (FCS) VolSafe Yes Media support for sport cartridge (xGB)
Sun StorageTek T10000B 4.6 (-06) Volsafe 5.2 Encryption qualified with StorageTek Crypto KMS 2.0.
Sun StorageTek T10000C 5.2 (-01) VolSafe 5.2 (-01)
  • Media support for sport cartridge (1TB) and Standard Cartridge (5TB)
  • Data Integrity Validation: 5.3 with Solaris 11, min. drive firmware = 1.53.315
  • Maximum Capacity option (5.5TB), min. drive firmware = 1.57.308.
Sun StorageTek T10000D
5.3-01
VolSafe
Yes
Supported through both FC or FCoE connections.  Minimum drive firmware 4.06.106.  With 5.3-01, T10000D tapes will show up as 5TB until first labelled.  After that they will show actual capacity (8TB).  T10000D is otherwise fully supported.  Initial capacity will show correctly in a future patch of SAM-QFS. Also, add the following entry to /kernel/drv/st.conf if not already present, and reboot:

st_dadp_settings=
         "STK     T10000C", "crc32c", "stk-crc32c",
         "STK     T10000D", "crc32c", "stk-crc32c"; <--- add this line

Comments

AndrewSayer

Kristofer wrote:

Our DBA created for us invisible index on a table that my team queries over a database link, reasoning that it will always be invisible so as to not impact other teams' transactions. This seems reasonable, and we were hoping to query the table in the following manner:

SELECT /*+ USE_INVISIBLE_INDEXES INDEX(t INDEX_NAME) */

FROM TABLE_NAME t

WHERE t.FIELD1 = 'VALUE'

We have tried this directly by logging into the remote database - the explain plan uses the invisible index. However when we try the following on our target database, with a database link, the explain plan shows it not using the invisible index but rather a suboptimal one:

SELECT /*+ USE_INVISIBLE_INDEXES INDEX(t INDEX_NAME) */

FROM TABLE_NAME@my_dblink t

WHERE t.FIELD1 = 'VALUE'

I've spent the better part of the past two days scouring the internet about using invisible indexes on remote tables, but my search has come up dry. It seems that we are unable to use invisible indexes on remote tables... but I don't know that definitively..

Is anyone familiar with using invisible indexes over dblinks? Is there a workaround that doesn't involve making it visible?

Thanks!

~Kris

Why not just test the impact that this query has with your other queries?

Remember that the cost based optimizer is only going to use an index if it deems it is cheaper than using some other access path. That's only gonna land you in hot water if your statistics don't represent your data.

You could embed a hint in a view on your remote DB:

ANDY@pdb1>explain plan for select /*+use_invisible_indexes*/* from as_inv_ind@loopback where col1 = :x;

Explained.

ANDY@pdb1>@X

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2105624835

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name      | Rows  | Bytes | Cost (%CPU)| Time    | Inst  |
----------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT REMOTE|            |    1 |  215 |    2  (0)| 00:00:01 |        |
|*  1 |  TABLE ACCESS FULL    | AS_INV_IND |    1 |  215 |    2  (0)| 00:00:01 |  PDB1 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - filter("A1"."COL1"=TO_NUMBER(:X))

Note
-----
  - fully remote statement
 
ANDY@pdb1>create or replace view as_inv_ind_vw as select /*+use_invisible_indexes*/* from as_inv_ind;

View created.

ANDY@pdb1>explain plan for select * from as_inv_ind_vw@loopback where col1 = :x;

Explained.

ANDY@pdb1>@X

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3477473690

-------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name        | Rows  | Bytes | Cost (%CPU)| Time    | Inst  |
-------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT REMOTE            |              |    1 |  215 |    1  (0)| 00:00:01 |        |
|  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| AS_INV_IND  |    1 |  215 |    1  (0)| 00:00:01 |  PDB1 |
|*  2 |  INDEX RANGE SCAN                  | AS_INV_IDX01 |    1 |      |    1  (0)| 00:00:01 |  PDB1 |
-------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  2 - access("COL1"=TO_NUMBER(:X))

Note
-----
  - fully remote statement

unknown-7404

Our DBA created for us invisible index on a table that my team queries over a database link, reasoning that it will always be invisible so as to not impact other teams' transactions.

Why? Why was an index created at all?

This seems reasonable, and we were hoping to query the table in the following manner:

It doesn't seem 'reasonable' to me.

We can ONLY reply based on the info you post.

And you haven't posted ANY info indicating you have any real problem.

Indexes are used to help solve a problem. If you don't have a problem you don't need an index.

Post info telling us WHAT PROBLEM you are trying to solve.

Also post any evidence you have supporting your conclusion that an 'index' (invisible or otherwise) will help solve that problem.

You are asking us to comment on your desired 'solution' - we need to know what the problem is you are trying to solve as well as other info such as the full version of the DBs you are trying to solve it on and the instance/session settings, if any, you used to make that index available to the optimizer.

I've spent the better part of the past two days scouring the internet about using invisible indexes on remote tables, but my search has come up dry.

Did you review the docs for CREATE INDEX?

https://docs.oracle.com/database/121/SQLRF/statements_5013.htm#SQLRF01209

VISIBLE | INVISIBLE  Use this clause to specify whether the index is visible or invisible to the optimizer. An invisible index is maintained by DML operations, but it is not be used by the optimizer during queries unless you explicitly set the parameter OPTIMIZER_USE_INVISIBLE_INDEXES to TRUE at the session or system level.

Have you set that parameter (notice that the NAME is not the same as the parameter used for the query hint)?

Perhaps your query works when you execute it directly on the remote DB because that parameter is TRUE on the remote DB.

But a query can ONLY be analyzed/executed on ONE DB. If you run a query on database A that references database B Oracle will only use ONE of those as the 'driving site'. That is the database that needs to have the parameter set.

ddf_dba

You may need to make the remote database the driving site before you can use any invisible indexes located there:

SELECT /*+ driving_site(t) USE_INVISIBLE_INDEXES INDEX(t INDEX_NAME) */

FROM TABLE_NAME@my_dblink t

WHERE t.FIELD1 = 'VALUE';

I can't be certain that this will work but it does allow remote queries to use remote indexes that aren't invisible.

David Fitzjarrell

1 - 3

Post Details