Test Credit Card Account Numbers

Numeros de tarjeta de crédito para hacer pruebas de desarrollo, fuente paypal: https://www.paypalobjects.com/en_GB/vhelp/paypalmanager_help/credit_card_numbers.htm

Base de Datos en estado Suspect

Recientemente he tenido que reparar para una empresa multinacional una base de datos que se encontraba marcada como sospechosa para lo cual utilice el script que muestro abajo y que origina este artículo, pero como la intención no es ejecutar cualquier código que encontramos solo porque sí, principalmente en bases de datos grandes y de producción, comprometiendo los datos de la empresa, me di a la tarea de explicar por qué el uso de cada instrucción, que resulto en este texto.

En las bases de datos se pueden presentar problemas por falla de hardware como por ejemplo mal funcionamiento en los controladores de discos o los discos duros en sí, también las interrupciones en el suministro de energía eléctrica ocasionan problemas ya que cuando detenemos los servicios del SQL Server de manera correcta se realiza un proceso interno para dar de baja las bases de datos, identificando las transacciones completas e incompletas para dejarlas en un estado consistente,  este proceso generalmente no pasa cuando el servidor se apaga inesperadamente lo que puede corromper las páginas de datos mediante escrituras incompletas que derivan en páginas de datos corruptas.

Relacionado con los antivirus, otra causa común que provoca corrupción en las páginas de datos es cuando SQL Server deja de tener acceso exclusivo a los archivos de datos y otros procesos los utilizan, por ejemplo cuando no se configuran las excepciones en los antivirus para excluir los archivos de las bases de datos, los proceso de verificación de virus cuando revisan los archivos de las bases de datos  eventualmente los corrompen.

Cuando se alcanza el umbral de 1000 páginas corruptas la base de datos se coloca en modo SUSPECT como mecanismo de autoprotección.

Para resolver este problema podemos ejecutar las siguientes sentencias:

EXEC SP_RESETSTATUS  [Base de Datos];ALTER DATABASE [Base de Datos] SET EMERGENCYDBCC CHECKDB ([Base de Datos])ALTER DATABASE [Base de Datos] SET SINGLE_USER WITH ROLLBACK IMMEDIATEDBCC CHECKDB ([Base de Datos], REPAIR_ALLOW_DATA_LOSS)ALTER DATABASE [Base de Datos] SET MULTI_USER

Ahora cual es la explicación de cada instrucción que usamos en el código anterior.

EXEC SP_RESETSTATUS  [Base de Datos];

Desactiva la marca de sospechoso de una base de datos. Este procedimiento actualiza las columnas de modo y estado de la base de datos con nombre en sys.databases. Se debe consultar el registro de errores de SQL Server y resolver todos los problemas antes de ejecutar este procedimiento. Después de ejecutar sp_resetstatus, detenga y reinicie la instancia de SQL Server

ALTER DATABASE [Base de Datos] SET EMERGENCY

Durante un proceso de recuperación de desastres, el estado de emergencia proporciona flexibilidad para realizar varias operaciones en una base de datos corrupta / sospechosa. Cuando se coloca una base de datos en el estado de emergencia, realiza tres cambios importantes en la configuración de la base de datos:

Set Emergency marca la base de datos como READ_ONLY, deshabilita el registro y el acceso está limitado a miembros del rol fijo de servidor sysadmin. Solamente los miembros del rol fijo de servidor sysadmin pueden establecer una base de datos en el estado EMERGENCY.

Aunque un estado sospechoso no es un requisito previo para poner una base de datos en un estado de emergencia, este es probablemente el momento más útil en el que se desea utilizar el estado de emergencia. Cuando una base de datos está en el estado de emergencia, puede acceder a sus datos, por lo que puede exportarla a otra base de datos e incluso puede ejecutar un DBCC CHECKDB en la base de datos para corregir la corrupción.

DBCC CHECKDB ([Base de Datos])

Comprueba la integridad física y lógica de todos los objetos de la base de datos especificada mediante la realización de las siguientes operaciones:

• Se ejecuta DBCC CHECKALLOC en la base de datos.
• Se ejecuta DBCC CHECKTABLE en cada tabla y vista en la base de datos.
• Se ejecuta DBCC CHECKCATALOG en la base de datos.
• Valida el contenido de cada vista indizada de la base de datos.
• Valida la coherencia de nivel de vínculo entre los archivos y directorios del sistema de archivos y metadatos de tabla al almacenar varbinary (max) datos del sistema de archivos con FILESTREAM.
• Valida los datos de Service Broker en la base de datos.

Esto significa que los comandos DBCC CHECKALLOC, DBCC CHECKTABLE o DBCC CHECKCATALOG no tienen que ejecutarse por separado de DBCC CHECKDB.

ALTER DATABASE [Base de Datos] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

El modo de usuario único se suele utilizar para operaciones de mantenimiento y especifica que solo un usuario puede tener acceso a la base de datos cada vez. La opción de terminación WITH ROLLBACK IMMEDIATE se especifica en la primera instrucción ALTER DATABASE . Esto hará que todas las transacciones incompletas se reviertan y que el resto de las conexiones a la base de datos se desconecten de inmediato.

DBCC CHECKDB ([Base de Datos], REPAIR_ALLOW_DATA_LOSS)

Especifica que DBCC CHECKDB repare los errores que encuentre, estas reparaciones pueden ocasionar alguna pérdida de datos. Utilice las opciones REPAIR solo como último recurso y tenga en cuenta que la base de datos especificada debe estar en modo de usuario único.

ALTER DATABASE [Base de Datos] SET MULTI_USER

Devuelve el acceso a la base de datos para todos los usuarios.

Este y otros temas de administración siguelos en el curso https://www.udemy.com/administracion-de-base-de-datos-con-sql-server/

PHP No Se Reconoce Como Comando Interno o Externo

Por cuestiones de trabajo me ha tocado trabajar con Magento un e-comerce durante el último año y recientemente tuve que formatear mi equipo y volver a configurar Apache usando Xampp en Windows 10.  Al trabajar con Magento para limpiar la cache o reindexar se tiene que ejecutar el comando "php bin/magento" acompañado de otras instrucciones pero al ejecutarlo recibí el mensaje de "php no se reconoce como comando interno o externo, programa o archivo por lotes ejecutable"
para resolver este error hicimos lo siguiente.

1, Abrimos la ventana de propiedades de Windows.

2. Luego hacemos clic en las opciones de la derecha en "Configuración Avanzada del Sistema"

3. En la ventana de Propiedades del Sistema, hacemos clic en la pestaña de Opciones Avanzadas y luego presionamos el botón de Variables de Entorno.

4. En el cuadro de abajo que es la sección de Variables del Sistema buscamos la opción de Path y hacemos doble clic, para abrir la ventana de variables de entorno.

5. En la ventana de variables de entorno, vamos a hacer clic en Nuevo y vamos a registrar el folder con la ubicación de los ejecutables de php, ubicados en la carpeta de Xampp > php, y listo.

6. Reiniciamos nuestra consola de comandos, y deberíamos poder utilizar el comando php.

Error al Iniciar Magento 2 Data Migration Version 1.25

Dese hace un año he estado involucrado en un proyecto con Magento y hemos tenido que migrar varias veces los datos de Magento 1.6 a Magento 2.2.4, pero en esta oportunidad la herramienta de Migración nos dio un error, así que lo documentamos para facilitar el trabajo en futuras oportunidades.

1. Descargamos del sitio la herramienta de migración del sitio: https://github.com/ubertheme/magento2_data_migration/releases

2.  Al descargar la carpeta en nuestro sitio y ejecutarlo nos devolvió el "Error 500" con los mensajes de php:

Notice: unserialize(): Unexpected end of serialized data in C:\xampp\htdocs\migracion\yii\caching\CCache.php on line 108

Notice: unserialize(): Error at offset 0 of 1 bytes in C:\xampp\htdocs\migracion\yii\caching\CCache.php on line 108

3. Para corregir este problema fuimos a abrir el archivo CCache.php ubicado en el folder yii>caching

4. Modificamos la línea 108 con la sintaxis: $value=unserialize($value); por el valor  $value=unserialize(base64_decode($value));

5. Y listo el problema se resolvió.

CHARLA SOBRE BACKUPS

Grabamos una sesión donde hablamos sobre backups, explicando primero las diferentes estrategias a partir de definir cada tipo de backup, luego en el segundo video ponemos manos a la obra y creamos los backups y restauramos para probar su funcioamiento, esto con el SQL Server de Microsoft

Limpiar la caché en Magento 2.2

Si has hecho modificaciones en tu tienda de Magento, estos no aparecerán de forma inmediata a menos de que la caché sea limpiada.

En Magento 2 puedes limpiar la caché desde el Administrador de Magento:
Ve a System -> Tools -> Cache Management. Selecciona Flush Magento Cache y después de que el proceso sea completado,  selecciona la opción. Flush Cache Storage.

Limpiar la caché por medio de SSH:

Para poder ejecutar estos comandos, es necesario que estés dentro de SSH, una vez dentro de la carpeta de tu Magento, ejecuta los siguientes comandos:
> php bin/magento cache:flush
> php bin/magento cache:clean