eckes's questions

Oracle 存在一个长期存在的（？）问题（？），如果您想对具有 B*-Tree 索引但可为空的列使用 DISTINCT 选择，则不使用该索引。（正如其他答案所暗示的那样，如果事后添加了一个受约束的检查（不存在空值），这甚至是正确的）。

有多种解决方法（包括使用 BITMAP 索引或向索引添加第二个 NON NULL 或常量列）。但是我刚刚注意到，如果我使用 WHERE NOT NULL 执行 SELECT DISTINCT，Oracle 能够使用索引（索引快速全扫描）。

我的问题：由于该行为存在于哪个 Oracle 版本，它是否可靠（何时首选两列索引）以及为什么没有更频繁地提及它（例如，这个原本很好的答案没有提及）？

小复制器

drop table SCOTT.T;
-- will not work with short rows (SELECT OWNER,SUBOBJECT_NAME ...)
create table SCOTT.T AS SELECT * FROM ALL_OBJECTS;
create index SCOTT.IDX_T_OWNER on SCOTT.T(OWNER); -- NOT NULL
-- (subobject_name,1) or (subobject_name,namespace) is NULL, NOT NULL
create index SCOTT.IDX_T_SUBOBJ on SCOTT.T(subobject_name); -- NULL
exec  dbms_stats.gather_table_stats(OWNNAME=>'SCOTT',TABNAME=>'T', cascade=>true );
desc SCOTT.T;

set autotrace on explain
-- fast index scan:
select distinct OWNER from SCOTT.T;
-- full table scan:
select distinct SUBOBJECT_NAME from SCOTT.T;
-- fast index scan:
select distinct SUBOBJECT_NAME from SCOTT.T where SUBOBJECT_NAME IS NOT NULL;

看起来（在 18c 上）类似于：

select distinct subobject_name from T;

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |   715 |  1430 |   436   (3)| 00:00:01 |
|   1 |  HASH UNIQUE       |      |   715 |  1430 |   436   (3)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| T    | 81426 |   159K|   428   (1)| 00:00:01 |
---------------------------------------------------------------------------


select distinct subobject_name from T where SUBOBJECT_NAME is not null;

------------------------------------------------------------------------------------
| Id  | Operation             | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |              |   624 |  1248 |     5  (20)| 00:00:01 |
|   1 |  HASH UNIQUE          |              |   624 |  1248 |     5  (20)| 00:00:01 |
|*  2 |   INDEX FAST FULL SCAN| IDX_T_SUBOBJ |  1459 |  2918 |     4   (0)| 00:00:01 |
------------------------------------------------------------------------------------

当我在其中运行一个会话时，psql它不会显示新创建的表（来自另一个连接，但对于当前所有者角色）。

如果我重新登录，它们就会出现。我是否需要以某种方式刷新 psql 缓存，或者这与事务/会话或缓存权限有关？

在 PostgreSQL 10 中 - 当使用“所有者用户”（拥有模式和所有表的登录角色，应用程序在运行时不使用）和“运行时”用户时，我可以GRANT选择/更新/删除模式中所有现有表的权限给运行时用户：

GRANT SELECT ON ALL TABLES IN SCHEMA owner TO runtime;

但这仅适用于现有对象，不适用于稍后可能创建的新表。

有没有办法通过继承角色或模式权限或类似方式来避免授予所有新对象？

我想知道 MS SQL Server 中未使用的索引。通过索引使用 DMV，我可以识别尚未用于搜索、扫描或查找的索引。

但是我从 Oracle 了解到，在执行计划中可能不会以这种方式使用索引，但是它仍然可以为 (Oracle) 优化器提供统计信息/基数信息。这种贡献没有以同样的方式进行监控。

所以我想知道在 MSSQL 中索引是否可以产生类似的积极效果，即使它没有直接使用（在代表性时间范围内）？具体来说，如果它可以比列统计更好（即删除索引是有害的）。

我在任何索引调优文章中都没有看到这个，所以我假设 MSSQL（直到 2017 年）没有这个概念，对吗？

我正在寻找有关回收站范围的信息。

删除表时，其段被重命名为“BIN$...”系统生成的名称，并且范围被隐藏。

这些范围仍然会阻止我缩小数据文件（或表空间）吗？如果是这样，我想在脚本中说明它们。

目前我正在使用受 AskTom 的 maxshrink.sql 启发的查询：

select tbs.TABLESPACE_NAME, df.FILE_NAME,
    round(MAX(e.BLOCKS+e.BLOCK_ID+1)*tbs.BLOCK_SIZE/1024/1024,2) "MinMB",
    round(MAX(df.BYTES)/1024/1024,2) "FileMB"
  from DBA_TABLESPACES tbs
  LEFT JOIN DBA_DATA_FILES df on tbs.TABLESPACE_NAME = df.TABLESPACE_NAME
  LEFT JOIN DBA_EXTENTS e on df.FILE_ID = e.FILE_ID AND df.RELATIVE_FNO = e.RELATIVE_FNO
  -- WHERE
  --   tbs.TABLESPACE_NAME like 'MY%'
  GROUP BY df.FILE_ID, df.RELATIVE_FNO, tbs.TABLESPACE_NAME, tbs.BLOCK_SIZE, df.FILE_NAME
  ORDER BY 1,2;

更新：最初我的问题还问我为什么在 12.2 中不再看到由 Flashback Drop Table 创建的“BIN$”段。然而，这对我来说是一个错误，我的测试表根本没有开始的段。

在使用 Oracle Golden Gate 将带有 Oracle RAC 数据库的主站点复制到辅助站点（和主动/主动备份）的场景中，我们怀疑未使用的辅助站点发生意外更改。

这个问题有点难以调试，因为我们没有直接的 DBA 访问权限。我想知道是否有一种简单的方法可以在主端进行非特权 SQL 访问，以查看是否从其他数据库收到任何更改？

我能否查看 OGG 活动的计数器或时间戳，以帮助我追踪所创建的 DML？

据我了解，在设置触发器或审核时，我可以看到 OGG 用户的更改 - 但是在这种情况下两者都不可用。

当我查看一些查询的实际执行计划时，我注意到 WHERE 子句中使用的文字常量显示为计算标量和常量扫描的嵌套链。

为了重现这一点，我使用下表

CREATE TABLE Table1 (
    [col1] [bigint] NOT NULL,
    [col2] [varchar](50) NULL,
    [col3] [char](200) NULL
)
CREATE NONCLUSTERED INDEX IX_Table1 ON Table1 (col1 ASC)

其中有一些数据：

INSERT INTO Table1(col1) VALUES (1),(2),(3),
                               (-9223372036854775808),
                               (9223372036854775807),
                               (2147483647),(-2147483648)

当我运行以下（无意义的）查询时：

SELECT a.col1, a.col2
  FROM Table1 a, Table1 b
  WHERE b.col1 > 2147483648

我看到它将在索引查找和标量计算（来自常量）的结果中进行嵌套循环绘图。

请注意，文字大于 maxint。它确实有助于写作CAST(2147483648 as BIGINT)。知道为什么 MSSQL 将其推迟到执行计划并且有没有比使用强制转换更短的方法来避免它？它是否也会影响到准备好的语句（来自 jtds JDBC）的绑定参数？

标量计算并不总是完成（似乎是特定于索引查找的）。有时查询分析器不会以图形方式显示它，而是col1 < scalar(expr1000)在谓词属性中显示。

我已经在 Windows 7 上使用 MS SSMS 2016 (13.0.16100.1) 和 SQL Server 2014 Expres Edition 64 位看到过这种情况，但我想这是一种普遍行为。