上周，应用人员误操作在平台上tablespace name 打错名字，从而想删除表空间进行重新建立。重建后此数据库备库触发了文件系统满的报警，备库文件系统使用率已经为100%，但是数据库值班人员观察到备库之前建立错误的数据文件已经不在，为何文件系统存储中文件却没有删掉？之前怎么没有出现如此的情况？
我随后做了一个实验给他，原因是在drop tablespace时，没有加上including contents and datafiles
--主库：
SQL> select username,count(*) from gv$session group by username order by 2 desc;
USERNAME COUNT(*)
------------------------------ ----------
174
ZABBIX 6
SYS 5
DBSNMP 4
PUBLIC 1
SQL>
SQL>
SQL>
SQL>
SQL>
SQL>
SQL> create tablespace albert datafile '+DG_DATA' size 1g;
Tablespace created.
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
UNDOTBS2
USERS
TBS_TEST_1025_1
TBS_TEST_1025_2
ALBERT --刚刚创建的表空间
FILE# NAME
---------- -----------------------------------------------------------------
1 +DG_DATA/Travelskydba/datafile/system.259.1002299725
2 +DG_DATA/Travelskydba/datafile/sysaux.260.1002299741
3 +DG_DATA/Travelskydba/datafile/undotbs1.261.1002299753
4 +DG_DATA/Travelskydba/datafile/undotbs2.263.1002299769
5 +DG_DATA/Travelskydba/datafile/users.264.1002299781
6 +DG_DATA/Travelskydba/datafile/tbs_test_1025_1.269.1022603323
7 +DG_DATA/Travelskydba/datafile/tbs_test_1025_2.270.1022603429
8 +DG_DATA/Travelskydba/datafile/albert.271.1035217783
--备库：
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
UNDOTBS2
USERS
TBS_TEST_1025_1
TBS_TEST_1025_2
ALBERT
SQL> select file#,name from v$datafile;
FILE# NAME
---------- -----------------------------------------------------------------
1 /oracle/oradata_Travelskydba/Travelskydba/system.259.1002299725
2 /oracle/oradata_Travelskydba/Travelskydba/sysaux.260.1002299741
3 /oracle/oradata_Travelskydba/Travelskydba/undotbs1.261.1002299753
4 /oracle/oradata_Travelskydba/Travelskydba/undotbs2.263.1002299769
5 /oracle/oradata_Travelskydba/Travelskydba/users.264.1002299781
6 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_1.269.1022603323
7 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_2.270.1022603429
8 /oracle/oradata_Travelskydba/Travelskydba/albert.271.1035217783
8 rows selected.
一、加入including contents and datafiles
--主库删除：
SQL> drop tablespace albert including contents and datafiles;
Tablespace dropped.
--备库确认，正常删除掉
SQL> select file#,name from v$datafile;
FILE# NAME
---------- -----------------------------------------------------------------
1 /oracle/oradata_Travelskydba/Travelskydba/system.259.1002299725
2 /oracle/oradata_Travelskydba/Travelskydba/sysaux.260.1002299741
3 /oracle/oradata_Travelskydba/Travelskydba/undotbs1.261.1002299753
4 /oracle/oradata_Travelskydba/Travelskydba/undotbs2.263.1002299769
5 /oracle/oradata_Travelskydba/Travelskydba/users.264.1002299781
6 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_1.269.1022603323
7 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_2.270.1022603429
7 rows selected.
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
UNDOTBS2
USERS
TBS_TEST_1025_1
TBS_TEST_1025_2
8 rows selected.
total 68780320
drwxr-xr-x 2 ora11g dba 4096 Oct 14 11:51 dataguardconfig
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl02.ctl.bak
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl01.ctl.bak
-rw-r----- 1 ora11g dba 10485768192 Oct 23 15:34 temp.262.1002299765
-rw-r----- 1 ora11g dba 2097160192 Mar 16 15:56 users.264.1002299781
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_2.270.1022603429
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_1.269.1022603323
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:35 sysaux.260.1002299741
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:35 undotbs1.261.1002299753
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:35 undotbs2.263.1002299769
-rw-r----- 1 ora11g dba 7340040192 Mar 16 16:35 system.259.1002299725
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:35 stdctl02.ctl
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:35 stdctl01.ctl
此时文件已经正常删除掉。
二、主库不加including contents and datafiles;
--主库创建文件：
SQL> create tablespace albert_leung datafile '+DG_DATA' size 2g;
Tablespace created.
--备库确认：
FILE# NAME
---------- -----------------------------------------------------------------
1 /oracle/oradata_Travelskydba/Travelskydba/system.259.1002299725
2 /oracle/oradata_Travelskydba/Travelskydba/sysaux.260.1002299741
3 /oracle/oradata_Travelskydba/Travelskydba/undotbs1.261.1002299753
4 /oracle/oradata_Travelskydba/Travelskydba/undotbs2.263.1002299769
5 /oracle/oradata_Travelskydba/Travelskydba/users.264.1002299781
6 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_1.269.1022603323
7 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_2.270.1022603429
8 /oracle/oradata_Travelskydba/Travelskydba/albert_leung.271.1035218283
8 rows selected.
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
UNDOTBS2
USERS
TBS_TEST_1025_1
TBS_TEST_1025_2
ALBERT_LEUNG
drwxr-xr-x 2 ora11g dba 4096 Oct 14 11:51 dataguardconfig
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl02.ctl.bak
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl01.ctl.bak
-rw-r----- 1 ora11g dba 10485768192 Oct 23 15:34 temp.262.1002299765
-rw-r----- 1 ora11g dba 2097160192 Mar 16 15:56 users.264.1002299781
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_2.270.1022603429
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_1.269.1022603323
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:35 sysaux.260.1002299741
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:38 undotbs1.261.1002299753
-rw-r----- 1 ora11g dba 2147491840 Mar 16 16:38 albert_leung.271.1035218283
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:38 undotbs2.263.1002299769
-rw-r----- 1 ora11g dba 7340040192 Mar 16 16:38 system.259.1002299725
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:38 stdctl02.ctl
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:38 stdctl01.ctl
--主库删除文件：
SQL> drop tablespace albert_leung;
Tablespace dropped.
--备库数据字典：
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
UNDOTBS2
USERS
TBS_TEST_1025_1
TBS_TEST_1025_2
8 rows selected
SQL> select FILE#,NAME from v$datafile;
FILE# NAME
---------- -----------------------------------------------------------------
2 /oracle/oradata_Travelskydba/Travelskydba/sysaux.260.1002299741
3 /oracle/oradata_Travelskydba/Travelskydba/undotbs1.261.1002299753
4 /oracle/oradata_Travelskydba/Travelskydba/undotbs2.263.1002299769
5 /oracle/oradata_Travelskydba/Travelskydba/users.264.1002299781
6 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_1.269.1022603323
7 /oracle/oradata_Travelskydba/Travelskydba/tbs_test_1025_2.270.1022603429
--可以看到，备库中的数据字典中已经删除掉，也就是说controlfile中该记录已经被删除
--但是观察到，备库文件系统，物理的数据文件还在，并没有删除。
[ora11g@vm-vmw45661-ora Travelskydba]$ ls -l
total 68780320
-rw-r----- 1 ora11g dba 2147491840 Mar 16 16:38 albert_leung.271.1035218283 --主库CHECKPOINT后不更新
drwxr-xr-x 2 ora11g dba 4096 Oct 14 11:51 dataguardconfig
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:43 stdctl01.ctl
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl01.ctl.bak
-rw-r----- 1 ora11g dba 24526848 Mar 16 16:43 stdctl02.ctl
-rw-r----- 1 ora11g dba 24526848 Oct 23 15:31 stdctl02.ctl.bak
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:41 sysaux.260.1002299741
-rw-r----- 1 ora11g dba 7340040192 Mar 16 16:41 system.259.1002299725
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_1.269.1022603323
-rw-r----- 1 ora11g dba 21474844672 Mar 16 15:56 tbs_test_1025_2.270.1022603429
-rw-r----- 1 ora11g dba 10485768192 Oct 23 15:34 temp.262.1002299765
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:41 undotbs1.261.1002299753
-rw-r----- 1 ora11g dba 5242888192 Mar 16 16:41 undotbs2.263.1002299769
-rw-r----- 1 ora11g dba 2097160192 Mar 16 15:56 users.264.1002299781
[ora11g@vm-vmw45661-ora Travelskydba]$
--此时，可以使用操作系统命令rm删除掉文件系统中命名错误的数据文件，因为controlfile中已经没有此记录，所以不会涉及数据库的实例恢复。
这个实验，没有加上including contents and datafiles 我只是回答了他第一个问题，但是第二个问题：“为什么之前我删除tablespace的时候，也没有加，怎么就没事呢？
根因在于Oracle Managed Files,这次出问题的此套备库没有使用OMF特性，也就是drop tablespace后，Oracle不会帮你自动的去清理物理文件，只会删除controlfile中的记录，但是之前同事所提到的没事的状况，是因为备库为RAC+ASM架构，默认采用了OMF管理数据文件，所以及时没有添加 including contents and datafiles 也会帮你自动清理文件。
官方原文如下：
1、 Unlike files that are not managed by the database, when an Oracle managed data file or temp file is dropped, the filename is removed from the control file and the file is automatically deleted from the file
2、 When recovery of a standby database encounters redo for the deletion of a tablespace, it deletes any Oracle managed data files in the local file system. Note that this is independent of the INCLUDING DATAFILES option issued at the primary database.
“Specify DEFAULT if you want to omit a limit for this resource in this profile. A user assigned this profile is subject to the limit for this resource specified in the DEFAULT profile. The DEFAULT profile initially defines unlimited resources. You can change those limits with the ALTERPROFILE statement.
Any user who is not explicitly assigned a profile is subject to the limits defined in the DEFAULT profile. Also, if the profile that is explicitly assigned to a user omits limits for some resources or specifies DEFAULT for some limits, then the user is subject to the limits on those resources defined by the DEFAULT profile.”
1.切换前确认主备库是否具备切换条件，关注是否Error与delay_time
select thread#,
DB_UNIQUE_NAME,
DEST_NAME,
TARGET,
DATABASE_MODE,
error,
RECOVERY_MODE,
GAP_STATUS,
APPLIED_SEQ#,
current_scn,
applied_scn,
to_char((scn_to_timestamp(current_scn)),'yyyymmdd hh24:mi:ss') current_scn_time,
to_char((scn_to_timestamp(applied_scn)),'yyyymmdd hh24:mi:ss') applied_scn_time,
scn_to_timestamp(current_scn)- scn_to_timestamp(current_scn) as delay_time
from (SELECT al.thread#,
ads.dest_id,
ads.DEST_NAME,
ads.TYPE || ' ' || ad.TARGET TARGET,
ADS.DATABASE_MODE,
ads.STATUS,
ads.error,
ads.RECOVERY_MODE,
ads.DB_UNIQUE_NAME,
ads.DESTINATION,
ads.GAP_STATUS,
(SELECT sequence#
FROM v$log na
WHERE na.thread# = al.thread#
and status = 'CURRENT') Current_Seq#,
Last_Archived,
al.APPLIED_SEQ#,
ad.applied_scn,
current_scn
FROM (SELECT dest_id,
thread#,
d.current_scn,
MAX(sequence#) Last_Archived,
max(CASE
WHEN APPLIED = 'YES' THEN
sequence#
end) APPLIED_SEQ#
FROM v$archived_log V, v$database d
WHERE V.resetlogs_change# = d.RESETLOGS_CHANGE#
group by dest_id, thread#, d.current_scn) al,
v$archive_dest_status ads,
v$archive_dest AD
WHERE al.dest_id(+) = ads.dest_id
AND ads.STATUS != 'INACTIVE'
AND AD.DEST_ID = ADS.DEST_ID and ad.APPLIED_SCN <> 0
ORDER BY al.thread#, ads.dest_id);
SQL> select name,database_role,switchover_status from v$database;
--确认为 to stanby或SESSIONS ACTIVE状态
2.SERVICE处理：
备库添加：
SQL> show parameter service;
NAME TYPE VALUE
------------------- ----------- ------------------------------
service_names string ORA1436B,dbaas
SQL> alter system set service_names='ORA1436B,dbaas,Albert';
System altered.
SQL> show parameter service;
NAME TYPE VALUE
---------------- ----------- ------------------------------
service_names string ORA1436B,dbaas,Albert
主库修改：
SQL> show parameter service;
NAME TYPE VALUE
-------------- ----------- ------------------------------
service_names string ORA1436B,dbaas,Albert
SQL> alter system set service_names='ORA1436B,dbaas';
System altered.
SQL> show parameter service;
NAME TYPE VALUE
------------- ----------- ------------------------------
service_names string ORA1436B,dbaas
3.RAC主库切换前保留1个节点
登陆到主库其他节点
SQL>SHUTDOWN IMMEDIATE
4.主库SWITCHOVER
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
或
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY with session shutdown;
注：如果有主库有活动的 session 可以使用此选项，否则转换会遇到 ORA-01093 错误或直接KILL活动会话
5.主库打开至Mount状态：
sqlplus / as sysdba
SQL> startup mount
6.备库SWITCH OVER操作
检查备库状态，是否可以切换
SQL> select name,database_role,switchover_status from v$database;
--确认是否为to primary
原备库取消恢复进程：
SQL> alter database recover managed standby database cancel;
原备库（新主库）switchover 操作
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
可能会抛出报ORA-16139: media recovery required，是是由于未应用日志引起，西药先执行执行 ：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
FROM SESSION;
8.原主库，新备库启用日志应用：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
9.确认主备库数据库数据字典状态与数据库日志有无异常，报错
select name,db_unique_name,database_role,open_mode from v$database;
主库进行日志切换，查看备库的日志，看是否开始接收并应用
SQL>select process,status,client_process,thread#,sequence#,block#,active_agents,known_agents from gv$managed_standby where process in ('LNS','RFS','MRP0') and THREAD# <> 0
备库：
SQL> show parameter service;
NAME TYPE VALUE
---------------------- ----------- ------------------------------
service_names string ORALIANGCE,dbaas
SQL> alter system set service_names='ORALIANGCE,dbaas,Albert';
System altered.
SQL> show parameter service;
NAME TYPE VALUE
----------------------- ----------- ------------------------------
service_names string ORALIANGCE,dbaas,Albert
主库：
SQL> show parameter service;
NAME TYPE VALUE
------------------------- ----------- ------------------------------
service_names string ORALIANGCE,dbaas,Albert
SQL> alter system set service_names='ORALIANGCE,dbaas';
System altered.
SQL> show parameter service;
NAME TYPE VALUE
--------------------------- ----------- ------------------------------
service_names string ORALIANGCE,dbaas
1.4 主备库配置，同步传输确认
主库上执行：
select thread#,
DB_UNIQUE_NAME,
DEST_NAME,
TARGET,
DATABASE_MODE,
error,
RECOVERY_MODE,
GAP_STATUS,
APPLIED_SEQ#,
current_scn,
applied_scn,
to_char((scn_to_timestamp(current_scn)),'yyyymmdd hh24:mi:ss') current_scn_time,
to_char((scn_to_timestamp(applied_scn)),'yyyymmdd hh24:mi:ss') applied_scn_time,
scn_to_timestamp(current_scn)- scn_to_timestamp(current_scn) as delay_time
from (SELECT al.thread#,
ads.dest_id,
ads.DEST_NAME,
ads.TYPE || ' ' || ad.TARGET TARGET,
ADS.DATABASE_MODE,
ads.STATUS,
ads.error,
ads.RECOVERY_MODE,
ads.DB_UNIQUE_NAME,
ads.DESTINATION,
ads.GAP_STATUS,
(SELECT sequence#
FROM v$log na
WHERE na.thread# = al.thread#
and status = 'CURRENT') Current_Seq#,
Last_Archived,
al.APPLIED_SEQ#,
ad.applied_scn,
current_scn
FROM (SELECT dest_id,
thread#,
d.current_scn,
MAX(sequence#) Last_Archived,
max(CASE
WHEN APPLIED = 'YES' THEN
sequence#
end) APPLIED_SEQ#
FROM v$archived_log V, v$database d
WHERE V.resetlogs_change# = d.RESETLOGS_CHANGE#
group by dest_id, thread#, d.current_scn) al,
v$archive_dest_status ads,
v$archive_dest AD
WHERE al.dest_id(+) = ads.dest_id
AND ads.STATUS != 'INACTIVE'
AND AD.DEST_ID = ADS.DEST_ID and ad.APPLIED_SCN <> 0
ORDER BY al.thread#, ads.dest_id)
[ora11g@~]$ dgmgrl
DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
DGMGRL> show configuration
Configuration - DG_Config
Protection Mode: MaxPerformance
Databases:
ORALIANGCE - Primary database
ORALIANGCEstd - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
2、查看主备库数据传输是否异常
DGMGRL>
DGMGRL> show database ORALIANGCEstd
Database - ORALIANGCEstd
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago)
Apply Lag: 0 seconds (computed 1 second ago)
Apply Rate: 13.00 KByte/s
Real Time Query: ON
Instance(s):
ORALIANGCE
Database Status:
SUCCESS
备库中的Transport Lag，Apply Lag是否正常
1.5 broker switcher切换
[ora11g@]$ dgmgrl
DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
DGMGRL> switchover to ORALIANGCEstd
Performing switchover NOW, please wait...
Operation requires a connection to instance "ORALIANGCE" on database "ORALIANGCEstd"
Connecting to instance "ORALIANGCE"...
Connected.
New primary database "ORALIANGCEstd" is opening...
Operation requires startup of instance "ORALIANGCE" on database "ORALIANGCE"
Starting instance "ORALIANGCE"...
ORACLE instance started.
Database mounted.
Database opened.
Switchover succeeded, new primary is "ORALIANGCEstd"
DGMGRL>
Broker会帮助你封装主备库实例启停，DG角色切换等命令
1.6 切换后检查
1.如RAC-RAC间切换，需要检查RAC各个节点是否启动
2.主备库数据字典检查
新主库：
SQL> select name,db_unique_name,database_role,open_mode from v$database;
NAME DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE
--------- ------------------------------ ---------------- --------------------
ORALIANGCE ORALIANGCE PHYSICAL STANDBY READ ONLY WITH APPLY
新备库：
SQL> select name,db_unique_name,database_role,open_mode from v$database；
SQL> set linesize 200
SQL> select process,status,client_process,thread#,sequence#,block#,active_agents,known_agents from gv$managed_standby where process in ('LNS','RFS','MRP0') and THREAD# <> 0;
PROCESS STATUS CLIENT_P THREAD# SEQUENCE# BLOCK# ACTIVE_AGENTS KNOWN_AGENTS
--------- ------------ -------- ---------- ---------- ---------- ------------- ------------
RFS IDLE LGWR 1 6864 469 0 0
MRP0 APPLYING_LOG N/A 1 6864 469 5 5
3.alert日志检查：需要仔细检查主备库的alert日志中有无其他ORA报错，如使用HugePage，需要确认HugePage是否正确。
4.应用SERVICE监听注册情况
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-2-1024x426.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-3-1024x329.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-13-1024x283.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200220-4-1024x803.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-6-1024x408.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-7-1024x591.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-10-1024x686.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200220-9-1024x517.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200221-11-1024x679.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200215-1-1024x621.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200215-2-1024x375.png)
![](http://albertdba.com/"wp-content/uploads"/2020/02/20200208-2-1024x41.png)
![20200127-1](http://albertdba.com/"wp-content/uploads"/2020/01/20200127-1.jpg)
![20200127-2](http://albertdba.com/"wp-content/uploads"/2020/01/20200127-2.jpg)
![20200127-3](http://albertdba.com/"wp-content/uploads"/2020/01/20200127-3.jpg)
![20200127-4](http://albertdba.com/"wp-content/uploads"/2020/01/20200127-4.jpg)
![20200127-5](http://albertdba.com/"wp-content/uploads"/2020/01/20200127-5.jpg)
![20200114-1](http://albertdba.com/"wp-content/uploads"/2020/01/20200114-1.jpg)
![20200123-11](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-11.png)
![20200123-13](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-13.png)
![20200123-16](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-16.png)
![20200123-17](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-17.png)
![20200121-1](http://albertdba.com/"wp-content/uploads"/2020/01/20200121-1.jpg)
![20200123-1](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-1.jpg)
![20200123-2](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-2.jpg)
![20200123-3](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-3.jpg)
![20200123-4](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-4.jpg)
![2020012305](http://albertdba.com/"wp-content/uploads"/2020/01/2020012305.jpg)
![20200123-6](http://albertdba.com/"wp-content/uploads"/2020/01/20200123-6.jpg)